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: bafug Freebsd 6.1 meeting
Julian Elischer wrote: The topic is "6.1... your questions answered" Is there any call for it to be streamed out? I ask because we usually stream the meetings when there is a speaker, but this is more round table.. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]" ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
bafug Freebsd 6.1 meeting
The topic is "6.1... your questions answered" Is there any call for it to be streamed out? ___ 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: BTX Halted on intel se7500wv2 + highpoint 1820a
On Friday 31 March 2006 20:27, Steven Hartland wrote: > The install of 6.1-BETA4 goes fine but after rebooting to the disk > I get: > FreeBSD/i385 bootstrap loader, Revision 1.1 > ([EMAIL PROTECTED], Tue Mar 14 94:42:47 UTC 2006) > Loading /boot/defaults/loader.conf > /boot/kernel/kernel text=0x4a49b4 \ > int=000d err=0013 efi=00010002 eip=0009f894 > eaz=00a1 ebx=0009c32e ecx= edx=00030206 > esi=fe881d64 edi=0009c348 ebp=17b4 esp=17ac > cs=0008 ds=9919 es=0010 fs= gs= ss=0010 > cs:eip=eb 05 d1 e9 f3 66 a5 5f-5e 55 c7 45 1c 00 00 00 >e2 fe 89 55 39 2b f7 89-75 28 61 83 c4 99 cf 61 > ss:exp=00 00 0c 00 f1 85 0c 00-44 c3 09 00 60 1d 88 fe >50 03 00 00 d4 17 00 00-04 00 00 00 09 00 00 00 > BTX halted > > Any ideas? > > Steve I think it's a bug in the loader. You can try to debug it by building a version of /boot/loader with symbols and seeing if you can reproduce it then lookup the eip value using gdb on the version of loader with symbols. You could also try to piece together parts of the call stack from the stack dump. -- John Baldwin <[EMAIL PROTECTED]> <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org ___ 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]"
