Re: uid of user who mounts

From: Steve French
Date: Fri Jul 30 2004 - 22:40:48 EST


Thanks - I had missed that - and it is a little cleaner to call it
"user" than "mount_uid" in the line in /proc/mounts, and there are no
existing parms returned that are similar (except "username" which should
be easy enough to understand). Interestingly I did not see other
filesystems returning that in /proc/mounts (I slightly prefer having it
stored in the filesystems kernel code and returned in showopts not just
put by userspace in the file mtab) - the only minor annoyance is that /
etc/mtab returns the username (rather than the uid).


On Fri, 2004-07-30 at 19:08 -0700, Randy.Dunlap wrote:
> 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

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/