RFC: Adding a ``user'' mount option

Stefan Sperling stsp at stsp.in-berlin.de
Thu Apr 6 23:42:55 UTC 2006


On Thu, Apr 06, 2006 at 12:37:03PM -0700, Darren Pilgrim wrote:
> >Access control is done via permissions of files in /dev. If I have
> >proper permissions to a device file, I can mount it at a directory
> >I own. If I don't have proper permissions to a device file, I cannot
> >mount it at all. This has nothing to do with fstab.
> 
> But it does.  GNOME/KDE provides a means of mounting devices by users that 
> would otherwise require a suid mount program.  If GNOME/KDE allowed this 
> functionality to be used directly with devices, rather than through fstab, 
> then without writing an parallel access control system into GNOME/KDE, 
> there would be nothing stopping a user from exploiting it to mount system 
> volumes.

So GNOME/KDE are already using suid binaries for mounting?
I do not see how else users would be able to mount arbitrary volumes.

People said they do not like suid binaries.
This is exactly what could be avoided with just using vfs.usermount
to control mounting from within KDE/GNOME. Proper access control system
is already there with vfs.usermount and /dev permissions. No need to
write a parallel system. There is one already - in fact, it looks
like GNOME/KDE are already duplicating functionality.

I don't really see a reason to have suid binaries at all if you
have something like vfs.usermount. It is much better than how Linux
does it (/bin/mount is setuid in Linux).

> >That's true - but you could provide sane default options, and make
> >them changable via the gui. If there are quotas on a file system,
> >or anything else you don't want the user to mess with, well, don't
> >give the user access to the device node in /dev.
> 
> That's the point exactly, we don't want users having direct access to the 
> device nodes.  fstab allows that by providing a means of referencing device 
> nodes without specifying them to the mount command and also allows devices 
> to be marked with the filesystem and mount options desired.  If GNOME/KDE 
> had code to parallel fstab, then the GNOME/KDE developers have to keep up 
> with changes to available filesystems and mount options for every supported 
> OS out there.  That's a lot of work just to parallel and already adequate 
> system.

It's true that changing the way GNOME and KDE operate involves lots of
porting work. But that's what the FreeBSD/KDE and FreeBSD/Gnome projects
are there for, aren't they? I bet they've made much larger adjustments
than changing they way mounts are handled (but I don't know and I'm just
bluntly guessing here).

And the current system is not adequate:
Consider massive multi-user installations, like university computer pools.
You don't want to list every student in fstab just so they can mount a CD
or a USB stick. I do not administrate an environment on that scale, but
I know people who do and they told me they find it easier to do
administrate large pools with Linux, because it has a user mount option
for fstab.
-- 
stefan
http://stsp.in-berlin.de                                 PGP Key: 0xF59D25F0



More information about the freebsd-hackers mailing list