Re: RFC: Adding a ``user'' mount option
On 08.04.2006, at 5:04, Jeremy Baggs wrote: I suppose it would be nice to have something that works "out of the box", but the solution I have been using is group permissions on the devices and then making the mount point in fstab relative instead of absolute. ie: /dev/cd0 cdrom cd9660 ro,noauto 0 0 Each user has a cdrom directory under their home directory. You still need mount points designated for all possible devices though. Does anyone know how Darwin / OsX are handling their auto-mount magic? There is a /Volumes folder, and each time user inserts usb flash or cd, the directory is created in that folder, named after a volume label, and mounts the media into newly created directory. Looks like the ``diskarbitrationd'' process is responsible for this. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: RFC: Adding a ``user'' mount option
I suppose it would be nice to have something that works "out of the box", but the solution I have been using is group permissions on the devices and then making the mount point in fstab relative instead of absolute. ie: /dev/cd0 cdrom cd9660 ro,noauto 0 0 Each user has a cdrom directory under their home directory. You still need mount points designated for all possible devices though. Does anyone know how Darwin / OsX are handling their auto-mount magic? Jeremy ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: RFC: Adding a ``user'' mount option
Anyway, I consider this to be a "hack" too :-) > Hello all, > > I've been watching this thread with some interest. > > I have actually found quite a straightforward solution to this problem that > works for me under FreeBSD, and requires no extra entries in fstab, scripts > changing permissions on login, or any other fairly ugly workaround. > > I assume that basically what we are looking for is to make > mounting/unmounting of devices as simple as possible for non-technical > users so they do not have to run mount manually at the command line. > > As mentioned before, you can easily globally restrict which users you wish > to allow mounting of a particular device by simply using group permissions > on the device. > > Then, assuming you've set vfs.usermount = 1: > > 1. ) First create some suitable directories under the user's /home folder > for mounting the devices. For example, I have: > > [= Yggdrasil | aren | /usr/home/aren =]% ls -l media > total 8 > drwxr-xr-x 2 aren aren 512 Apr 6 21:37 cdrw/ > drwxr-xr-x 2 aren aren 512 Apr 6 13:19 dvdrom/ > drwxr-xr-x 2 aren aren 512 Apr 6 15:03 floppy/ > drwxr-xr-x 2 aren aren 512 Apr 6 14:04 usbflash/ > > 2.) Next, add the devices icons to your KDE (or whichever) desktop. > > 3.) Now KDE by default will use the mount point specified under > /etc/fstab. Obviously this is no good, since the current user will not own > the mount point specified. However, if you simply open up the actual > desktop device file, it is a very straightforward text file. You can then > simply edit the "MountPoint" entry to point to the new mount location under > your home folder. > > For example, for my DVD-ROM drive desktop link: > > [= Yggdrasil | aren | /usr/home/aren/Desktop =]% cat DVD-ROM > [Desktop Action Eject] > Exec=kdeeject %v > Name=Eject > > [Desktop Entry] > Actions=Eject; > Dev=/dev/cd1 > Encoding=UTF-8 > Icon=dvd_mount > MountPoint=/home/aren/media/dvdrom > FSType=cd9660 > ReadOnly=true > Type=FSDevice > UnmountIcon=dvd_unmount > X-KDE-Priority=TopLevel > > > The "FSType" entry is not usually there by default either, but it helps to > make sure that the correct option is called to mount. > > > > Mounting a device is as simple as just clicking on the desktop icon now, > which is exactly what we wanted. It will mount the device under the mount > location in my /home, which I own, and everything works great. > > This method requires no alteration/extra entries in /etc/fstab, no chown on > a global mount location (since the user always owns their own local mount > point), no sudo and no setuid. Minimal security compromise. > > For a large network, it should be fairly trivial to create a script that > will add the users to the correct group(s) for mouting the given device(s), > create the necessary mount directories under the user's /home directory, > and populate their KDE (or whichever) desktop with the correct (modified) > desktop entries. Job done. > > Regards, > > Aren. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: RFC: Adding a ``user'' mount option
Hello all, I've been watching this thread with some interest. I have actually found quite a straightforward solution to this problem that works for me under FreeBSD, and requires no extra entries in fstab, scripts changing permissions on login, or any other fairly ugly workaround. I assume that basically what we are looking for is to make mounting/unmounting of devices as simple as possible for non-technical users so they do not have to run mount manually at the command line. As mentioned before, you can easily globally restrict which users you wish to allow mounting of a particular device by simply using group permissions on the device. Then, assuming you've set vfs.usermount = 1: 1. ) First create some suitable directories under the user's /home folder for mounting the devices. For example, I have: [= Yggdrasil | aren | /usr/home/aren =]% ls -l media total 8 drwxr-xr-x 2 aren aren 512 Apr 6 21:37 cdrw/ drwxr-xr-x 2 aren aren 512 Apr 6 13:19 dvdrom/ drwxr-xr-x 2 aren aren 512 Apr 6 15:03 floppy/ drwxr-xr-x 2 aren aren 512 Apr 6 14:04 usbflash/ 2.) Next, add the devices icons to your KDE (or whichever) desktop. 3.) Now KDE by default will use the mount point specified under /etc/fstab. Obviously this is no good, since the current user will not own the mount point specified. However, if you simply open up the actual desktop device file, it is a very straightforward text file. You can then simply edit the "MountPoint" entry to point to the new mount location under your home folder. For example, for my DVD-ROM drive desktop link: [= Yggdrasil | aren | /usr/home/aren/Desktop =]% cat DVD-ROM [Desktop Action Eject] Exec=kdeeject %v Name=Eject [Desktop Entry] Actions=Eject; Dev=/dev/cd1 Encoding=UTF-8 Icon=dvd_mount MountPoint=/home/aren/media/dvdrom FSType=cd9660 ReadOnly=true Type=FSDevice UnmountIcon=dvd_unmount X-KDE-Priority=TopLevel The "FSType" entry is not usually there by default either, but it helps to make sure that the correct option is called to mount. Mounting a device is as simple as just clicking on the desktop icon now, which is exactly what we wanted. It will mount the device under the mount location in my /home, which I own, and everything works great. This method requires no alteration/extra entries in /etc/fstab, no chown on a global mount location (since the user always owns their own local mount point), no sudo and no setuid. Minimal security compromise. For a large network, it should be fairly trivial to create a script that will add the users to the correct group(s) for mouting the given device(s), create the necessary mount directories under the user's /home directory, and populate their KDE (or whichever) desktop with the correct (modified) desktop entries. Job done. Regards, Aren. pgprdvGZRpCF3.pgp Description: PGP signature
Re: RFC: Adding a ``user'' mount option
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 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: RFC: Adding a ``user'' mount option
In <[EMAIL PROTECTED]>, Jilles Tjoelker <[EMAIL PROTECTED]> typed: > Consider chown(8)ing the mount points to the current user on login (and > root on logout) (using DisplayManager._0.startup and > DisplayManager._0.reset or similar). /etc/fbtab is designed for exactly this problem. That's what I use. http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: RFC: Adding a ``user'' mount option
On Tue, Apr 04, 2006 at 01:45:47PM +0200, Stefan Sperling wrote: > Why do GNOME/KDE rely on /etc/fstab on FreeBSD? > What are admins supposed to do on systems with more than, say, a hundred > users. Having to add a line to /etc/fstab for every user is of course > scriptable, but that does not make it less insane. > As far as I got it, the current design boils down to the user creating > a mount point, and then mounting the media "manually", e.g. > mount /dev/cd0 ~/cdrom. Granted the admin has set vfs.usermount to 1, > of course. I don't really think that user mount has been designed > with /etc/fstab in mind. Consider chown(8)ing the mount points to the current user on login (and root on logout) (using DisplayManager._0.startup and DisplayManager._0.reset or similar). I do this on a few multiuser boxes (at most 5 users per box though) and all users can use the same /etc/fstab lines. The mount will only work for the locally logged in user, which may be considered a bug or a feature ;-) -- Jilles Tjoelker ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Re: RFC: Adding a ``user'' mount option
On Thu, 6 Apr 2006, Peter Jeremy wrote: On Wed, 2006-Apr-05 12:14:29 -0500, Rick C. Petty wrote: If not operator, then maybe one configurable group, defaulting to operator. Sounds like a good idea. -- Peter Jeremy What group do NFS and SMBFS shares belong to? Mike "Silby" Silbersack ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Re: RFC: Adding a ``user'' mount option
On Wed, 2006-Apr-05 12:14:29 -0500, Rick C. Petty wrote: >On Tue, Apr 04, 2006 at 10:00:00AM -0500, Sergey Babkin wrote: >> >> Would it make sense to be able to specify a group in fstab? >> Then the users can be simply given membership of this >> group to mount the devices. > >Why not just assume allowable users are in the "operator" group. Isn't >this what that group was designed for? That group was designed for people who ran backups - it's hard-coded in dump(8). >If not operator, then maybe one configurable group, defaulting to operator. Sounds like a good idea. -- Peter Jeremy ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Re: RFC: Adding a ``user'' mount option
On Tue, Apr 04, 2006 at 10:00:00AM -0500, Sergey Babkin wrote: > > Would it make sense to be able to specify a group in fstab? > Then the users can be simply given membership of this > group to mount the devices. Why not just assume allowable users are in the "operator" group. Isn't this what that group was designed for? I certainly setup my boxes to give users permission to access the soundcard and other "operators of this machine" devices... If not operator, then maybe one configurable group, defaulting to operator. Admins who want special circumstances can use devfs rules to set the group for certain devices. This way, we use unix-isms such as: 1). can the user mount filesystems? (vfs.usermount) 2). does the user have permissions to the device? (e.g. group-read/write to said device) 3). does the user have permissions to the mountpoint? (e.g. user read/write/execute) -- Rick C. Petty ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: RFC: Adding a ``user'' mount option
On Wed, 5 Apr 2006, Stefan Sperling wrote: I wasn't serious. Sudo is fine by me as well. However, having something that is in the base system (and not in ports) to allow user mounts would be neat. Still, KDE and GNOME and even xorg are in ports as well, so that point is not a really strong one either. The only thing that still nags me about the sudo solution is that if you have to use sudo anyway, why was vfs.usermount even implemented in the first place? Using sudo makes it redundant. Well, there are some notions that vfs.usermount captures that other variations currently don't. One of those is the idea that the kernel will have direct access to the credentials used to authorize the mount, rather than the kernel being passed a root credential. This becomes interesting when there are file systems without an integrated notion of file ownership (such as msdosfs), or for file systems that will make use of user keying material or access files and services using the privileges of the user (i.e., distributed file systems). For example, NFS uses the privileges of the user performing the mount to create sockets, access the network, etc. Whether this ends up being important in the big picture is another question, but there is an important semantic difference there from the perspective of kernel access control. Robert N M Watson ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: RFC: Adding a ``user'' mount option
On Wed, Apr 05, 2006 at 01:37:11PM +0100, Jan Grant wrote: > On Wed, 5 Apr 2006, Stefan Sperling wrote: > > > On Tue, Apr 04, 2006 at 09:52:17PM -0800, [EMAIL PROTECTED] wrote: > > > > > > > So why not have GNOME/KDE create mount points for the user if > > > > vfs.usermount is 1? > > > pardon my ignorance, but how any of those methods described earlier may > > > be superior to simply using sudo? > > > > Using sudo is a hack? :) > > I don't buy that aesthetic argument. I wasn't serious. Sudo is fine by me as well. However, having something that is in the base system (and not in ports) to allow user mounts would be neat. Still, KDE and GNOME and even xorg are in ports as well, so that point is not a really strong one either. The only thing that still nags me about the sudo solution is that if you have to use sudo anyway, why was vfs.usermount even implemented in the first place? Using sudo makes it redundant. -- stefan http://stsp.in-berlin.de PGP Key: 0xF59D25F0 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: RFC: Adding a ``user'' mount option
On Wed, 5 Apr 2006, Stefan Sperling wrote: > On Tue, Apr 04, 2006 at 09:52:17PM -0800, [EMAIL PROTECTED] wrote: > > > > > So why not have GNOME/KDE create mount points for the user if > > > vfs.usermount is 1? > > pardon my ignorance, but how any of those methods described earlier may > > be superior to simply using sudo? > > Using sudo is a hack? :) Using sudo is using a small, well-inspected tool to do a well-defined job as part of a toolchain. Stringing such tools together is where the unix environment derives its expressive power from. So I'd second the question; I don't buy that aesthetic argument. -- jan grant, ISYS, University of Bristol. http://www.bris.ac.uk/ Tel +44 (0)117 3317661 http://ioctl.org/jan/ Solution: (n) a watered-down version of something neat. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Re: RFC: Adding a ``user'' mount option
>From: Stefan Sperling <[EMAIL PROTECTED]> >What are admins supposed to do on systems with more than, say, a hundred >users. Having to add a line to /etc/fstab for every user is of course >scriptable, but that does not make it less insane. Would it make sense to be able to specify a group in fstab? Then the users can be simply given membership of this group to mount the devices. -SB ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: RFC: Adding a ``user'' mount option
On Tue, Apr 04, 2006 at 09:52:17PM -0800, [EMAIL PROTECTED] wrote: > > > So why not have GNOME/KDE create mount points for the user if > > vfs.usermount is 1? > pardon my ignorance, but how any of those methods described earlier may > be superior to simply using sudo? Using sudo is a hack? :) -- stefan http://stsp.in-berlin.de PGP Key: 0xF59D25F0 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: RFC: Adding a ``user'' mount option
> So why not have GNOME/KDE create mount points for the user if > vfs.usermount is 1? Since FreeBSD uses devfs, every device in /dev that > usually represents a device with removable media can assumed to be > present in hardware. GNOME/KDE could be patched to create mount points > somewhere in the user's home directory, and issue a 'mount device > mount_point' > instead of 'mount mount_point' if the user clicks the device icon. pardon my ignorance, but how any of those methods described earlier may be superior to simply using sudo? Timestamp: 0x44335A44 [SorAlx] http://cydem.org.ua/ ridin' VN1500-B2 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: RFC: Adding a ``user'' mount option
Stefan Sperling wrote: Why do GNOME/KDE rely on /etc/fstab on FreeBSD? GNOME/KDE could be patched to create mount points somewhere in the user's home directory, and issue a 'mount device mount_point' instead of 'mount mount_point' if the user clicks the device icon. Limiting GNOME/KDE to just those mounts listed in /etc/fstab provides a mechanism of access control. If GNOME/KDE allowed user mounts of any device, then it would become possible for users to mount umounted system volumes. Using fstab also makes it possible for GNOME/KDE to mount items with mount options (sync, mode limits, quotas, etc.) and just rely on the system to get it right, rather than having system-specific, parallel mount code. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: RFC: Adding a ``user'' mount option
On Tue, Apr 04, 2006 at 02:47:18AM -0400, Joe Marcus Clarke wrote: > On Tue, 2006-04-04 at 08:30 +0200, Alex Dupre wrote: > > Joe Marcus Clarke wrote: > > > What I'd like to achieve is a simple out-of-the-box way of mounting > > > media such as CDs, and floppy disks without users necessarily needing to > > > know about sysctl. While I can't speak for KDE, I know GNOME already > > > has the ability to detect user-mountable media, and gives the users > > > icons on the desktop to mount said volumes. > > > > I don't know what exactly you mean with 'detect user-mountable media', > > but a KDE user may have desktop icons for every device/fs listed in > > /etc/fstab. I assume GNOME works in a similar way. And clicking on the > > icon of course will mount the media with the 'mount' command. KDE also > > monitor changes to the fstab file and can open a dialog window when a > > new media appears, but since the fstab file is not automatically updated > > on FreeBSD (I don't know how it works exactly on Linux) this feature is > > quite useless. > > GNOME works in a similar fashion. Currently if vfs.usermount=1, FreeBSD > scans the fstab list, and if the mount point is owned by the current > user, it adds an icon for it. Why do GNOME/KDE rely on /etc/fstab on FreeBSD? What are admins supposed to do on systems with more than, say, a hundred users. Having to add a line to /etc/fstab for every user is of course scriptable, but that does not make it less insane. As far as I got it, the current design boils down to the user creating a mount point, and then mounting the media "manually", e.g. mount /dev/cd0 ~/cdrom. Granted the admin has set vfs.usermount to 1, of course. I don't really think that user mount has been designed with /etc/fstab in mind. So why not have GNOME/KDE create mount points for the user if vfs.usermount is 1? Since FreeBSD uses devfs, every device in /dev that usually represents a device with removable media can assumed to be present in hardware. GNOME/KDE could be patched to create mount points somewhere in the user's home directory, and issue a 'mount device mount_point' instead of 'mount mount_point' if the user clicks the device icon. This still requires novice home desktop users to set vfs.usermount to 1 though, so it's not a perfect solution. But it prevents having another suid binary just for convinience, and is suitable for large multi user installations. > For dynamic updates, Linux has mtab. For FreeBSD (in GNOME, that is), > we just periodically check for changes in the list of available file > systems. Where? In /etc/fstab or /dev ? -- stefan http://stsp.in-berlin.de PGP Key: 0xF59D25F0 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: RFC: Adding a ``user'' mount option
On Mon, 2006-04-03 at 23:30 +0100, Robert Watson wrote: > On Mon, 3 Apr 2006, Joe Marcus Clarke wrote: > > >> I would suggest that an extremely careful security audit of the userspace > >> and kernel mount and unmount code is due -- especially things like the > >> per-filesystem mount code (mount_nfs, etc). I'm not against the principle > >> of this though. > > > > Agreed. I was hoping to make this solution secure, flexible, and easy to > > use. > > Sure. And if you don't commit bug fixes to mount, we'll know you haven't > tried looking very hard, because it seems very likely to me it has problems > :-). > > >> Also, I'm not 100% sure we should make the getuid() check return a hard > >> error in user space. Let's continue to let the kernel code make the > >> access > >> control decision here. > > > > I did the check in user space so that I could read the fstab file, and know > > that the volume was allowed to be user-[un]mounted. I suppose, though, > > that > > I could set the flags in user space, then pass that to the kernel for the > > actual access control decision as you say. > > I'm not entirely clear on what ideal is, but one possibility is to allow the > user mount bit to determine whether the mount system call is invoked with > privilege. Thanks for the feedback. I'll try and release an updated diff this weekend that incorporates your suggestions, and I'll attempt the wildcard suggestion made by silby. Joe > > Robert N M Watson > -- Joe Marcus Clarke FreeBSD GNOME Team :: [EMAIL PROTECTED] FreeNode / #freebsd-gnome http://www.FreeBSD.org/gnome signature.asc Description: This is a digitally signed message part
Re: RFC: Adding a ``user'' mount option
On Tue, 2006-04-04 at 08:30 +0200, Alex Dupre wrote: > Joe Marcus Clarke wrote: > > What I'd like to achieve is a simple out-of-the-box way of mounting > > media such as CDs, and floppy disks without users necessarily needing to > > know about sysctl. While I can't speak for KDE, I know GNOME already > > has the ability to detect user-mountable media, and gives the users > > icons on the desktop to mount said volumes. > > I don't know what exactly you mean with 'detect user-mountable media', > but a KDE user may have desktop icons for every device/fs listed in > /etc/fstab. I assume GNOME works in a similar way. And clicking on the > icon of course will mount the media with the 'mount' command. KDE also > monitor changes to the fstab file and can open a dialog window when a > new media appears, but since the fstab file is not automatically updated > on FreeBSD (I don't know how it works exactly on Linux) this feature is > quite useless. GNOME works in a similar fashion. Currently if vfs.usermount=1, FreeBSD scans the fstab list, and if the mount point is owned by the current user, it adds an icon for it. For dynamic updates, Linux has mtab. For FreeBSD (in GNOME, that is), we just periodically check for changes in the list of available file systems. Joe > > -- > Alex Dupre > -- Joe Marcus Clarke FreeBSD GNOME Team :: [EMAIL PROTECTED] FreeNode / #freebsd-gnome http://www.FreeBSD.org/gnome signature.asc Description: This is a digitally signed message part
Re: RFC: Adding a ``user'' mount option
Joe Marcus Clarke wrote: > What I'd like to achieve is a simple out-of-the-box way of mounting > media such as CDs, and floppy disks without users necessarily needing to > know about sysctl. While I can't speak for KDE, I know GNOME already > has the ability to detect user-mountable media, and gives the users > icons on the desktop to mount said volumes. I don't know what exactly you mean with 'detect user-mountable media', but a KDE user may have desktop icons for every device/fs listed in /etc/fstab. I assume GNOME works in a similar way. And clicking on the icon of course will mount the media with the 'mount' command. KDE also monitor changes to the fstab file and can open a dialog window when a new media appears, but since the fstab file is not automatically updated on FreeBSD (I don't know how it works exactly on Linux) this feature is quite useless. -- Alex Dupre ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: RFC: Adding a ``user'' mount option
On Mon, 3 Apr 2006, Joe Marcus Clarke wrote: I would suggest that an extremely careful security audit of the userspace and kernel mount and unmount code is due -- especially things like the per-filesystem mount code (mount_nfs, etc). I'm not against the principle of this though. Agreed. I was hoping to make this solution secure, flexible, and easy to use. Sure. And if you don't commit bug fixes to mount, we'll know you haven't tried looking very hard, because it seems very likely to me it has problems :-). Also, I'm not 100% sure we should make the getuid() check return a hard error in user space. Let's continue to let the kernel code make the access control decision here. I did the check in user space so that I could read the fstab file, and know that the volume was allowed to be user-[un]mounted. I suppose, though, that I could set the flags in user space, then pass that to the kernel for the actual access control decision as you say. I'm not entirely clear on what ideal is, but one possibility is to allow the user mount bit to determine whether the mount system call is invoked with privilege. Robert N M Watson ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: RFC: Adding a ``user'' mount option
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Robert Watson wrote: > On Mon, 3 Apr 2006, Joe Marcus Clarke wrote: > >> I know we have vfs.usermount, but this is not always sufficient since >> the user has to own the mount point in question. What I propose is to >> add a ``user'' mount option à la Linux. This would make mount and >> umount setuid root, but would allow much more flexibility when it >> comes to removable media and desktop systems. > > I would suggest that an extremely careful security audit of the > userspace and kernel mount and unmount code is due -- especially things > like the per-filesystem mount code (mount_nfs, etc). I'm not against > the principle of this though. Agreed. I was hoping to make this solution secure, flexible, and easy to use. > > Also, I'm not 100% sure we should make the getuid() check return a hard > error in user space. Let's continue to let the kernel code make the > access control decision here. I did the check in user space so that I could read the fstab file, and know that the volume was allowed to be user-[un]mounted. I suppose, though, that I could set the flags in user space, then pass that to the kernel for the actual access control decision as you say. Joe > > Robert N M Watson > >> >> I'm not a src committer, so this isn't a threat to commit. I'm more >> interested in getting feedback, and hopefully some src committer >> interest. I think this would really benefit desktop FreeBSD. >> >> http://www.marcuscom.com/downloads/usermount.diff >> >> Joe >> >> -- >> Joe Marcus Clarke >> FreeBSD GNOME Team :: [EMAIL PROTECTED] >> FreeNode / #freebsd-gnome >> http://www.FreeBSD.org/gnome >> - -- Joe Marcus Clarke FreeBSD GNOME Team :: [EMAIL PROTECTED] FreeNode / #freebsd-gnome http://www.FreeBSD.org/gnome -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEMWyrb2iPiv4Uz4cRAoEsAJ9FIdAHhxxD37KCw0ma8vs5OUySigCeJbjg UYa4Bjjb9l1F46XGHulZTAI= =qlHM -END PGP SIGNATURE- ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: RFC: Adding a ``user'' mount option
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Colin Percival wrote: > Joe Marcus Clarke wrote: >> I know we have vfs.usermount, but this is not always sufficient since >> the user has to own the mount point in question. What I propose is to >> add a ``user'' mount option à la Linux. This would make mount and >> umount setuid root, but would allow much more flexibility when it comes >> to removable media and desktop systems. > > If I understand the patch correctly, you're proposing that some filesystems > be marked as "this can be mounted or unmounted by non-root users". If this > is correct, it seems to me that a more appropriate solution is to add an > /etc/usermount.conf file and a new setuid utility usermount(8) which would > look at the invoking user and the filesystem requested and either pass the > request to mount(8) or reject it. As others have pointed out, the way mounting works now is fine for most advanced users (it's fine for me, as I wrote the FAQ for GNOME). However, for newer users, they don't get that removable media mounting doesn't work out-of-the-box. Other operating systems don't have this extra complexity. For example, Linux uses the user mount notation. Solaris has volume management such that media like CDs are auto-mounted, and instantly made available to users. > > Generally speaking it's much better to add a new setuid program which does > exactly what you need, rather than making an existing and possibly insecure > program setuid. What I'd like to achieve is a simple out-of-the-box way of mounting media such as CDs, and floppy disks without users necessarily needing to know about sysctl. While I can't speak for KDE, I know GNOME already has the ability to detect user-mountable media, and gives the users icons on the desktop to mount said volumes. I was hoping we could make this solution secure and flexible without the need for another utility. Joe - -- Joe Marcus Clarke FreeBSD GNOME Team :: [EMAIL PROTECTED] FreeNode / #freebsd-gnome http://www.FreeBSD.org/gnome -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD4DBQFEMWOHb2iPiv4Uz4cRAu8uAJjr8GMUcLMmf764FVtfdq/ZAkSbAJ9qLVxK mtV+SNR6h+/YDjCD8mKA5Q== =rc6p -END PGP SIGNATURE- ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: RFC: Adding a ``user'' mount option
On Mon, 3 Apr 2006, Joe Marcus Clarke wrote: I know we have vfs.usermount, but this is not always sufficient since the user has to own the mount point in question. What I propose is to add a ``user'' mount option à la Linux. This would make mount and umount setuid root, but would allow much more flexibility when it comes to removable media and desktop systems. I would suggest that an extremely careful security audit of the userspace and kernel mount and unmount code is due -- especially things like the per-filesystem mount code (mount_nfs, etc). I'm not against the principle of this though. Also, I'm not 100% sure we should make the getuid() check return a hard error in user space. Let's continue to let the kernel code make the access control decision here. Robert N M Watson I'm not a src committer, so this isn't a threat to commit. I'm more interested in getting feedback, and hopefully some src committer interest. I think this would really benefit desktop FreeBSD. http://www.marcuscom.com/downloads/usermount.diff Joe -- Joe Marcus Clarke FreeBSD GNOME Team :: [EMAIL PROTECTED] FreeNode / #freebsd-gnome http://www.FreeBSD.org/gnome ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: RFC: Adding a ``user'' mount option
On Mon, 3 Apr 2006, Joe Marcus Clarke wrote: I know we have vfs.usermount, but this is not always sufficient since the user has to own the mount point in question. What I propose is to add a ``user'' mount option ? la Linux. This would make mount and umount setuid root, but would allow much more flexibility when it comes to removable media and desktop systems. I'm not a src committer, so this isn't a threat to commit. I'm more interested in getting feedback, and hopefully some src committer interest. I think this would really benefit desktop FreeBSD. http://www.marcuscom.com/downloads/usermount.diff Joe That is a very useful feature, I think it would be a welcome addition to FreeBSD. Making it work for floppies / CDs should be pretty easy, but since you're adding it as a new feature for us, can you consider making it even more flexible? What I mean is this: We have smbfs support. It would be nice if usermount supported wildcards, so that you could say that user home directories on the samba server 10.2.2.3 could be usermounted by users to the "fileserver" directory in their home directory. If that worked out of the box, it would really rock. Basic usermount support only would require you to add an entry for each user, which is not convenient. Mike "Silby" Silbersack___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: RFC: Adding a ``user'' mount option
Simon L. Nielsen wrote: > Any reason you can't just use sudo... ? Because we are talking about desktop users. There are many ways to let user mount devices, but nothing that works oob (or at least with very few changes) with all desktop environments. Few of them allow to mount removable media with sudo (for example I cannot find such feature on KDE). You can say it's a KDE problem, you may be right, but the result is that using FreeBSD as a regular (not power) desktop user is less pratical. -- Alex Dupre ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: RFC: Adding a ``user'' mount option
On 2006.04.03 01:32:36 -0400, Joe Marcus Clarke wrote: > I know we have vfs.usermount, but this is not always sufficient since > the user has to own the mount point in question. What I propose is to > add a ``user'' mount option à la Linux. This would make mount and > umount setuid root, but would allow much more flexibility when it comes > to removable media and desktop systems. Any reason you can't just use sudo... ? I simply have lines like: simon ALL=NOPASSWD:/sbin/mount /mnt/cdrom,/sbin/umount /mnt/cdrom in my sudoers file [1]. This way I can also restrict exactly who can mount. I really dislike setuid root binaries, so I really prefer if we could avoid adding more. As Colin noted, if this is to be done via a setuid program, it probably should be a new program, since setuid programs has to have a lot of special handling of things like file descriptors etc. which normal programs can safely ignore. [1] Note I haven't checked if this opens new and interesting holes, but it doesn't matter too much on my laptop, since if somebody has access to "simon" that's just as bad as someone getting root. -- Simon L. Nielsen pgpyE4Mezbwos.pgp Description: PGP signature
Re: RFC: Adding a ``user'' mount option
Colin Percival wrote: > Generally speaking it's much better to add a new setuid program which does > exactly what you need, rather than making an existing and possibly insecure > program setuid. Generally speaking I agree with you. To minimize the impact of having to run a different 'mount' executable (that I doubt desktop environments will likely do) it would be nice if 'mount' could automatically run 'usermount' if called by a regular user. -- Alex Dupre ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: RFC: Adding a ``user'' mount option
Joe Marcus Clarke wrote: > I know we have vfs.usermount, but this is not always sufficient since > the user has to own the mount point in question. What I propose is to > add a ``user'' mount option à la Linux. This would make mount and > umount setuid root, but would allow much more flexibility when it comes > to removable media and desktop systems. If I understand the patch correctly, you're proposing that some filesystems be marked as "this can be mounted or unmounted by non-root users". If this is correct, it seems to me that a more appropriate solution is to add an /etc/usermount.conf file and a new setuid utility usermount(8) which would look at the invoking user and the filesystem requested and either pass the request to mount(8) or reject it. Generally speaking it's much better to add a new setuid program which does exactly what you need, rather than making an existing and possibly insecure program setuid. Colin Percival ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: RFC: Adding a ``user'' mount option
Hi Joe, On Mon, 3 Apr 2006, 01:32-0400, Joe Marcus Clarke wrote: > I know we have vfs.usermount, but this is not always sufficient since > the user has to own the mount point in question. What I propose is to > add a ``user'' mount option ? la Linux. This would make mount and > umount setuid root, but would allow much more flexibility when it comes > to removable media and desktop systems. Personally I have no problems with vfs.usermount and removal medias on FreeBSD-based desktops but a new suid binary in the system just scare me. -- Maxim Konovalov ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: RFC: Adding a ``user'' mount option
Joe Marcus Clarke wrote: > I know we have vfs.usermount, but this is not always sufficient since > the user has to own the mount point in question. What I propose is to > add a ``user'' mount option à la Linux. This would make mount and > umount setuid root, but would allow much more flexibility when it comes > to removable media and desktop systems. I can't speak about security implications or your implementation, but this is surely a long awaited and wished feature for desktop users. Adding dozens of entries in devfs.conf and creating user owned mount points is not very pratical. -- Alex Dupre ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: RFC: Adding a ``user'' mount option
В сообщении от Понедельник 03 Апрель 2006 12:32 Joe Marcus Clarke написал(a): > I know we have vfs.usermount, but this is not always sufficient since > the user has to own the mount point in question. What I propose is to > add a ``user'' mount option à la Linux. This would make mount and > umount setuid root, but would allow much more flexibility when it comes > to removable media and desktop systems. > > I'm not a src committer, so this isn't a threat to commit. I'm more > interested in getting feedback, and hopefully some src committer > interest. I think this would really benefit desktop FreeBSD. > > http://www.marcuscom.com/downloads/usermount.diff > > Joe Totally right! For me it is a huge problem at home. On the other hand, I think we are not telling something new. There must be some security reasons or something, otherwise I think this feature could already exist... Am I wrong? I wish I were. -- С уважением, Бачило Дмитрий Руководитель отдела системной интеграции ООО "Компания СоЛинк" ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
