DragonFly BSD
DragonFly submit List (threaded) for 2003-09
[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]

Re: mount user option


From: Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>
Date: Wed, 24 Sep 2003 09:32:42 -0700 (PDT)

:>     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

    Right.

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

    Right.

:c) user does not need rw-access to device
:regarding c), ro-access should still be required
:

    I don't see a problem with rw-access.  e.g. removable media needs rw
    access.  It would be controlled by the fstab.

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

    User would only be able to mount from fstab entries and would have no
    control over the mount point.

: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 ;)

    Correct, or if the user is running chroot'd.

: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).

    This is too dangerous, generally speaking.

:######
: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!

    I think we can stick with the same system call and have an suid
    'usermount' program deal with the user mounts.

:
: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.

    The flag idea is fine.  I don't think we should be renaming system calls.
    We can use the same system call (it doesn't know the difference).  I'm
    reversing myself from previous emails but it occurs to me that if
    usermount is suid then as far as the system is concerned it will be a
    'root' euid that is doing the mounting.

: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 ;).

    Exactly!

:well, this it is.
:do we agree?
:
:~ibotty

    I think its on the right track.  I will test and review whatever code you
    develop.

					-Matt
					Matthew Dillon 
					<dillon@xxxxxxxxxxxxx>



[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]