Re: mount user option

[ibotty <bsd@xxxxxxxxxx>]

>     Most of the functionality should probably be in the kernel,
>     but /etc/fstab is still going to govern what the user can and
>     cannot mount which implies an suid program of some sort.

i am still uncertain about the goals.

so the requirements of usermount are:

a) only let LOCAL users (owning the system console) mount

b) only mounting of fstab entries with 'user' option are allowed.

c) user does not need rw-access to device

d) user should mount on specified mountpoint (e.g. on /cdrom, not own file) 



regarding c), ro-access should still be required

i am open, on whether d) should be implemented. 
it is desired, to ease users.
when we have different views of the filesystem we can of course implement
this as per-user /cdrom ;)
if i should not implement d), we should still force the user to mount the
cdrom at ~/cdrom (or ~/Volumes/cdrom, just prepending $HOME before the
fstab mount point).



######
implementation:

i have looked at the mount(2) syscall code (in vfs_syscalls.c).
it is trivial to set the owner of the mount to the uid (instead of the
euid). 
i am not entirely sure, that we want to do this with all mount()s.
well, the question is, should i copy the mount(2) syscall to (say..)
usermount(2), which sets this flag.
notice: the difference is only this single flag!


so i propose following design (ehem, well design...):

KERNEL changes:
mv mount(2) realmount(2), add a flag, to indicate, that the uid should be
set as the owner.
and make mount(2) and usermount(2) wrapper around realmount(2).

this all could be safely in one mount(2), all it would require is an
additional flag (say MNT_SETUID) in mount.h.

USERLAND:
the binary usermount(8) would be 4555.
it would check /etc/fstab if the user is allowed to mount.
and call mount(8).
this in turn would call (somewhen) mount(2).

usermount should be fairly easy to secure.
it would only take ONE parameter ;).


well, this it is.
do we agree?

~ibotty