mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Randy.Dunlap" <rddunlap@osdl.org>
To: Steve French <smfrench@austin.rr.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: uid of user who mounts
Date: Fri, 30 Jul 2004 19:08:25 -0700	[thread overview]
Message-ID: <20040730190825.7a447429.rddunlap@osdl.org> (raw)
In-Reply-To: <1091239509.3894.11.camel@smfhome.smfdom>

On Fri, 30 Jul 2004 21:05:09 -0500 Steve French wrote:

| To allow user unmounts of cifs shares (much like the setuid smbumount
| utility allows for smbfs), it has been suggested that the cifs vfs could
| return the uid of the mounter in /proc/mounts  This would avoid having
| to add an ioctl (as smbfs did) and seems as secure as the ioctl approach
| (to get the uid of the original mounter).
| 
| If user mounts are allowed, is there any worse security exposure in
| letting the tool check the uid who mounted via /proc/mounts (to allow
| user unmount).   
| 
| Is there any precedent for the name for the name of such a parm?  I was
| thinking of "mnt_uid" since simply using "uid=" would seem to overload
| the meaning of "uid", which is already used as a mount parm by various
| filesystems to signify the default uid for files ( ie in the cifs case
| when mounting to Windows - and Unix CIFS protocol extensions are not
| enabled) and it is not always the case that the default uid for files
| would be the same as the uid of the person who mounted.

For the last question, looks like "user=" is already used for that.
See 'man mount':

              user   Allow  an  ordinary  user to mount the file system.  The
                     name of the mounting user is written to mtab so that  he
                     can  unmount the file system again.  This option implies
                     the options noexec, nosuid, and nodev (unless overridden
                     by   subsequent   options,   as   in   the  option  line
                     user,exec,dev,suid).



--
~Randy

  reply	other threads:[~2004-07-31  2:17 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-07-31  2:05 Steve French
2004-07-31  2:08 ` Randy.Dunlap [this message]
2004-07-31  3:34   ` Steve French
2004-07-31  9:35     ` Miklos Szeredi
2004-07-31 15:21       ` Steve French
2004-07-31 17:31         ` Miklos Szeredi
2004-07-31 17:49           ` Steve French
2004-07-31 18:12         ` Steve French
2004-07-31 19:11         ` Andries Brouwer
2004-07-31 19:43           ` Miklos Szeredi

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20040730190825.7a447429.rddunlap@osdl.org \
    --to=rddunlap@osdl.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=smfrench@austin.rr.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®