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: Tue, 23 Sep 2003 09:33:06 -0700 (PDT)

:On Tuesday, September 23, 2003, at 09:09 AM, ibotty wrote:
:
:> this patch allows mount(8) to handle a 'user' option in fstab(5), as in
:> linux.
:>
:> advantages:
:>  - user do not need to be able to write to the device to mount it.
:>  - no need for the vfs.usermount sysctl(8)
:>
:> the attached patch has some drawbacks:
:>  1) /sbin/mount needs to be suid root.
:>  2) it byepasses vfs.usermount security checks.
:>  3) a user currently cannot umount the filesystem ;-p
:>
:These drawbacks listed are considerable. I think there will be a better
:approach in a few weeks as work on the VFS subsystem finishes up.
:With that noted the three drawbacks listed are very severe.
:
:-DR

    I have to agree with David here.  The ability to do a user mount is
    desireable, but we can't approach it in this fashion.  We should
    probably have an entirely new utility to handle user mounts and unmounts,
    maybe call it 'usermount', so we can separate out the security issues.  

    I would then restrict 'usermount' to root or whoever currently owns the
    system console.  As you know, the system console tends to be held by the
    user id owning the X session so this would be a good way to determine
    who is actually sitting in front of the machine.  We definitely cannot
    allow the program to be run by any user.

    vfs.usermount is a terrible hack as it stands, but it can serve as 
    a framework for the console ownership check. 

    A user-mounted filesystem could be flagged such that it can be
    similarly unmounted.

					-Matt
					Matthew Dillon 
					<dillon@xxxxxxxxxxxxx>



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