Messages in this thread | | | Subject | Re: uid of user who mounts | From | Steve French <> | Date | Fri, 30 Jul 2004 22:34:01 -0500 |
| |
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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |