I understand there are a lot of smart people with a lot of great ideas trying to make the boot process faster stronger better. I am sure their stuff will be great when it is done, but for right here and now I think my way is the best out of the box, for a desktop. Then again who really cares how a server boots up, that should happen at most twice a year if the systems administrator is any good.
Here is my Fedora 7 clean desktop and what happens. All default things I install and use. I will give some comments.
S04dkms_autoinstaller <- already talked about on the dev list. I have the code on my machine that does this when the kernel rpm is installed if a dkms module fails to compile it uses grubby to fail boot to the old kernel ( needs user notification and some way to re-run dkms with updated packages and decide if it should boot the new kernel ) S04readahead_early <- in my new config actually slows down boot. I want to move this code to a really early that runs from rc.sysinit before gdm/rhgb starts S05kudzu <- in my config could theoretically be an X app with a lot better gui S06cpuspeed <- gone. I dumped the cpuspeed daemon and have moved everything to use the in kernel governors and modules. I need a better interface for this but for now I load all the modules in /etc/sysconfig/modules and set ondemand as the default. This configuration allows you to change the governor or statically set the cpu freq through the gnome applet. S07iscsid <- useless without network connectivity moved to a dispatcher.d script S08ip6tables <- can be set here but should also be restarted by dispatcher for future location change switches S10network <- removed for a desktop install. Handled by NetworkManagerDispatcher S11auditd S12restorecond S12syslog S13irqbalance <- not needed yet ( do we really need processes balanced on processors until we are doing anything? ) S13iscsi <- removed for a desktop install. Handled by NetworkManagerDispatcher S13mcstrans S13rpcbind <- removed for a desktop install. Handled by NetworkManagerDispatcher S13setroubleshoot S14nfslock <- removed for a desktop install. Handled by NetworkManagerDispatcher S15mdmonitor <- not needed yet ( This is desktop if we are running a raid can wait until we have a gui to know abou tit ) S18rpcidmapd <- removed for a desktop install. Handled by NetworkManagerDispatcher S19rpcgssd <- removed for a desktop install. Handled by NetworkManagerDispatcher S22messagebus <- I think the system messagebus should be moved to my early-gdm config. start it up way early, everything uses it and it isn't like it should be turned on and off. S25bluetooth <- should be started by udev/hal if appropriate bluetooth devices are detected S25netfs <- removed for a desktop install. Handled by NetworkManagerDispatcher S26hidd <- should be started by udev/hal if appropriate bluetooth devices are detected S28autofs <- should be started by udev/hal if appropriate bluetooth devices are detected S50hplip <- should only be started if cups has a printer setup that uses it. Possibly run by udev/hal. S55cups <- This is a background process for the desktop. Until there is a gui printing is worthless. S55sshd <- removed for a desktop install. Handled by NetworkManagerDispatcher S56xinetd <- removed for a desktop install. Handled by NetworkManagerDispatcher (maybe?) S58ntpd <- removed for a desktop install. Everything handled by NetworkManager S90ConsoleKit S90crond <- dumped I am using fcron S90xfs <- gone S95anacron <- dumped I am using fcron S95atd <- dumped I am using fcron S96readahead_later <- should be run through gdm PreFetchProgram directive for a desktop S97dhcdbd <- gone with NM 7.0 S98avahi-daemon <- removed for a desktop install. Handled by NetworkManagerDispatcher S98haldaemon <- should be way earlier in the boot process for a desktop S99firstboot S99local
So what do we get with my setup. GDM is the first thing out of nash that starts. In the Init portion of gdm we start up rhgb and then wait unit it ends to start the greeter. This means we can stop rhgb anytime in the init process and login. I choose to stop it at S50. So I put all my "essential" desktop services pre S50 and all my server/post login services after S50. This gives me.
rc.sysinit
(I also move the acpi module section to /etc/sysconfig/modules ) /etc/sysconfig/modules/ acpi.modules cpugov.modules kvm.modules udev-stw.modules
-> Starts system dbus -> early-gdm -> defers scheduled fsck's to shutdown ( still working on a good gui for this )
S11auditd S12restorecond S12syslog S13mcstrans S13nscd S22messagebus S25bluetooth S30haldaemon S35fcron S40dhcdbd S41NetworkManager S42NetworkManagerDispatcher Here we get the "parallel" boot that everyone talks about. Based on whether the network is up or down we get. S04iscsi S05iscsid S10ntpd S15autofs S16netfs I have both these scripts checking if necessary rpc services are running and starting them if necessary. S15sshd S20avahi-daemon S25avahi-dnsconfd S60iscsi-target S45ConsoleKit S50GDMGreeter ( yeah we can login ) S55cups S60mysqld S61httpd S64lm_sensors .....this list can be any other services that are non-essential to login. S99local
There it is short sweet. No fancy magic other than change some text and symlinks. It gives cpugov and speed control in userspace and fixes problems with network services dying when NM changes networks ( Dispatcher restarts things that helps clean up bad states ). Of course the services based on hardware aren't there, however that should easily be added to existing udev rules. On my Athlon 2500+ with a 7200 pata drive 8MB cache I go from power on to signon in 37 seconds, from grub selection I am between 28- 30 seconds to login screen.
This method isn't perfect, but it works and takes no extra software. Things can be made better by make rhgb use two way fifo pipes so the entire init process can be redirected to it's vte, and we can export the early-gdm X-server so exitsting text/X processes can use X instead of ncurses. I am just proposing an option to something that doesn't exist yet.
Jon
On 9/12/07, Jon Nettleton jon.nettleton@gmail.com wrote:
S42NetworkManagerDispatcher Here we get the "parallel" boot that everyone talks about. Based on whether the network is up or down we get. S04iscsi S05iscsid S10ntpd S15autofs S16netfs I have both these scripts checking if necessary rpc services are running and
Question here from the peanut gallery. Do you still have chkconfig and system-config-services "control" of the services being handled by Dispatcher?
-jef
On Thu, 2007-09-13 at 14:07 -0800, Jeff Spaleta wrote:
On 9/12/07, Jon Nettleton jon.nettleton@gmail.com wrote:
S42NetworkManagerDispatcher Here we get the "parallel" boot that everyone talks about. Based on whether the network is up or down we get. S04iscsi S05iscsid S10ntpd S15autofs S16netfs I have both these scripts checking if necessary rpc services are running and
Question here from the peanut gallery. Do you still have chkconfig and system-config-services "control" of the services being handled by Dispatcher?
That will probably need some work. I think you'd probably want to have a tab for these nm dispatcher services similar to the xined-based services. If you want to go wild, one could also imagine having a list of system bus dbus services there...
On 9/13/07, Matthias Clasen mclasen@redhat.com wrote:
That will probably need some work. I think you'd probably want to have a tab for these nm dispatcher services similar to the xined-based services. If you want to go wild, one could also imagine having a list of system bus dbus services there...
I think the control issue is probably the only note-worthy regression that I see with this approach. I've no qualms with using Dispatcher for network-related services, with a couple of caveats. 1) basic on/off control ..exactly on par with xinetd based services as you suggest.
2) what to do we do when NM is turned off and the older sysconfig based networking configuration is used. There should be a way to hold the service configs for these network services so they are boot-time operable (if turned on) in situations where NM isn't being run and the legacy sysconfig based networking configs are being used.
-jef
On 9/13/07, Jeff Spaleta jspaleta@gmail.com wrote:
On 9/13/07, Matthias Clasen mclasen@redhat.com wrote:
That will probably need some work. I think you'd probably want to have a tab for these nm dispatcher services similar to the xined-based services. If you want to go wild, one could also imagine having a list of system bus dbus services there...
I think the control issue is probably the only note-worthy regression that I see with this approach. I've no qualms with using Dispatcher for network-related services, with a couple of caveats.
- basic on/off control ..exactly on par with xinetd based services
as you suggest.
- what to do we do when NM is turned off and the older sysconfig
based networking configuration is used. There should be a way to hold the service configs for these network services so they are boot-time operable (if turned on) in situations where NM isn't being run and the legacy sysconfig based networking configs are being used.
I can think of two approaches.
a) Do this in system-config-services. Checking NetworkManager and Dispatcher on makes the Network-Services tab active and disables "known services" from the init list and enables them in the Network-Services list. Disabling these does the reverse of course.
b) Only have these services in the Network-Services tab or run-level N for chkconfig and extend /etc/init.d/network to run through the /etc/NetworkManager/dispatcher.d/ directory and run the S* services. This message is a little off because it basically puts partial init functionality in the network script. The code should be trivial though.
Jon
On Thu, 2007-09-13 at 19:06 -0400, Jon Nettleton wrote:
I can think of two approaches.
a) Do this in system-config-services. Checking NetworkManager and Dispatcher on makes the Network-Services tab active and disables "known services" from the init list and enables them in the Network-Services list. Disabling these does the reverse of course.
b) Only have these services in the Network-Services tab or run-level N for chkconfig and extend /etc/init.d/network to run through the /etc/NetworkManager/dispatcher.d/ directory and run the S* services. This message is a little off because it basically puts partial init functionality in the network script. The code should be trivial though.
Don't get too attached to tabs in system-config-services. My plan is to get rid of them altogether and have all services (SysVinit-, xinetd- and eventually network-based or (more generically) on-demand services) in one list. Each entry in this list would consist of the service name, its enabled/disabled and running/not running status. Now selecting an entry would finally show the gory details: type of service, in which runlevels it is enabled/disabled in case of a SysVinit service, etc.
Now what I really don't want to do is deal with service type transitions (NMD gets stopped -> network-based services get normal SysVinit services again) as I don't see real value behind it. If network-based services need a daemon to run properly then it better ran. It's not really a new situation -- if xinetd doesn't run, xinetd-based services don't get started. Just as with every other basic building block of the system.
Makes sense?
Nils
On Fri, 2007-09-14 at 23:11 +0200, Nils Philippsen wrote:
Now what I really don't want to do is deal with service type transitions (NMD gets stopped -> network-based services get normal SysVinit services again) as I don't see real value behind it. If network-based services need a daemon to run properly then it better ran. It's not really a new situation -- if xinetd doesn't run, xinetd-based services don't get started. Just as with every other basic building block of the system.
Makes sense?
As long as it will be able to support both traditional networking setups (for servers) and NM-based setups, it should be fine. I don't think going back and forth between these two at runtime is very interesting.
On Fri, 2007-09-14 at 17:15 -0400, Matthias Clasen wrote:
On Fri, 2007-09-14 at 23:11 +0200, Nils Philippsen wrote:
Now what I really don't want to do is deal with service type transitions (NMD gets stopped -> network-based services get normal SysVinit services again) as I don't see real value behind it. If network-based services need a daemon to run properly then it better ran. It's not really a new situation -- if xinetd doesn't run, xinetd-based services don't get started. Just as with every other basic building block of the system.
Makes sense?
As long as it will be able to support both traditional networking setups (for servers) and NM-based setups, it should be fine.
That should be possible, as long as s-c-services can properly distinguish between the two types -- at the moment everything in /etc/init.d is treated as a SysVinit service. As I understand it, "on-demand" or "event-triggered" services, and whatever they're called that's what these "network-based" services are, shall be started through dbus in the long run. I don't think adding kludges in s-c-services to support an artificial runlevel "N" for that is a good thing to do.
I don't think going back and forth between these two at runtime is very interesting.
No. Actually I think that one service can be startable through both SysVinit and on-demand by dbus and s-c-services should in that case offer control over both types. It might be a bit tricky to do UI wise, but I think this nut is crackable ;-).
Nils
On 9/13/07, Jeff Spaleta jspaleta@gmail.com wrote:
On 9/12/07, Jon Nettleton jon.nettleton@gmail.com wrote:
S42NetworkManagerDispatcher Here we get the "parallel" boot that everyone talks about. Based on whether the network is up or down we get. S04iscsi S05iscsid S10ntpd S15autofs S16netfs I have both these scripts checking if necessary rpc services are running and
Question here from the peanut gallery. Do you still have chkconfig and system-config-services "control" of the services being handled by Dispatcher?
I tentatively have a working config. I added N as another runlevel that chkconfig can turn on and off. The problem is that the scripts are slightly different for NMDispatcher than standard init. I am starting to lean more towards having another tab in system-config-services that manages them like xinetd. I am open to suggestions though.
Jon
On 9/13/07, Jon Nettleton jon.nettleton@gmail.com wrote:
I tentatively have a working config. I added N as another runlevel that chkconfig can turn on and off. The problem is that the scripts are slightly different for NMDispatcher than standard init. I am starting to lean more towards having another tab in system-config-services that manages them like xinetd. I am open to suggestions though.
exposing NMDispatcher controlled services like xinetd is handled now is probably fine. Here's the next question.
How do you add more services to NMDispatcher's control? From a packager's perspective what do I have to do to ship a package with a network based service script? Am I going to have to ship two different versions of the script? One for the legacy network system and another for the NMDispatcher?
-jef
On 9/13/07, Jeff Spaleta jspaleta@gmail.com wrote:
On 9/13/07, Jon Nettleton jon.nettleton@gmail.com wrote:
I tentatively have a working config. I added N as another runlevel that chkconfig can turn on and off. The problem is that the scripts are slightly different for NMDispatcher than standard init. I am starting to lean more towards having another tab in system-config-services that manages them like xinetd. I am open to suggestions though.
exposing NMDispatcher controlled services like xinetd is handled now is probably fine. Here's the next question.
How do you add more services to NMDispatcher's control? From a packager's perspective what do I have to do to ship a package with a network based service script? Am I going to have to ship two different versions of the script? One for the legacy network system and another for the NMDispatcher?
Sure now you start answering the hard questions. Well the scripts I use are all based around the same generic dispatcher.d script. The only variance is whether you check in /var/lock/subsys or /var/run to figure out if the daemon is always running. Other than that they just run service NAMEOFSERVICE on/off/restart. If we could standardize and put all our lock files or pid files in a single place then we could run a single script from dispatcher.d that wraps symlinks put in /etc/rc.d/rcN.d/ and does the appropriate thing to the service.
hmmm, that is confusing.
/etc/NetworkManager/dispatcher.d/network-services on interface up it loops through /etc/rc.d/rcN.d/S(*) and either service $1 start or service $1 restart depending whether /var/run/$1 exists or not.
Now that I look at it like that does it make sense to make network-services an actual init-script that is responsible for for /etc/rc.d/rcN.d/
If we are running NetworkManager it is activated through dispatcher.d, otherwise we just enable it in standard init after network.
I think that should work.
Jon
On Thu, 2007-09-13 at 19:19 -0400, Jon Nettleton wrote:
Sure now you start answering the hard questions. Well the scripts I use are all based around the same generic dispatcher.d script. The only variance is whether you check in /var/lock/subsys or /var/run to figure out if the daemon is always running. Other than that they just run service NAMEOFSERVICE on/off/restart. If we could standardize and put all our lock files or pid files in a single place then we could run a single script from dispatcher.d that wraps symlinks put in /etc/rc.d/rcN.d/ and does the appropriate thing to the service.
hmmm, that is confusing.
/etc/NetworkManager/dispatcher.d/network-services on interface up it loops through /etc/rc.d/rcN.d/S(*) and either service $1 start or service $1 restart depending whether /var/run/$1 exists or not.
Now that I look at it like that does it make sense to make network-services an actual init-script that is responsible for for /etc/rc.d/rcN.d/
If we are running NetworkManager it is activated through dispatcher.d, otherwise we just enable it in standard init after network.
I think that should work.
So I talked a bit to Dan Williams about this today, and he said that the dispatcher will need a bit of love for NM 0.7 to handle the fact that there will possibly be multiple active interfaces, and one default interface. Services could adapt to changes in the set of available interfaces in smarter ways than just ifup -> service start, ifdown -> service stop.
Correct me if I am misremembering, Dan.
Hi,
If I understand correctly, the main goal is to make it faster for the user to see the login screen. It seems simpler then to just move the login screen earlier in the boot process (i.e. before all the stuff conditional on the network) rather than making everything depend on networking, which just happens to not be started until login.
Some of the stuff starting here doesn't make sense outside of a server also...autofs, iscsi etc. We've been just killing that stuff by default for the desktop spin.
Actually reading this, you have moved GDM very early - but your boot time speedup gains are presumably because you're not starting these services at all until after login?
On 9/13/07, Colin Walters walters@redhat.com wrote:
Actually reading this, you have moved GDM very early - but your boot time speedup gains are presumably because you're not starting these services at all until after login?
My speed gains come from three basic principles
1) I start 1 X server for the whole boot process. I am running rhgb in /etc/gdm/Init/Default before gdm-chooser is run. This gives me two niceties, 1 x-server, as soon as I kill rhgb-client gdm-chooser launches.
2) I am achieving parallel boot by allowing NMD start services as necessary. There is no reason starting a bunch of network dependent services on boot if we don't have link, or wireless because we haven't logged in yet and started nm-applet. As far as the services you call "server" services, well those are just what I run, and I use all of them on my desktop on my home network. I use autofs for my file-services and icsi to connect ot my NAS for backups. This technology will slowly start making to more and more peoples desktops, it is just senseless to start it if you don't have a network connection.
3) I am re-ordering system services that ignore "server services" until after we get to a desktop login. We need dbus, hal, network, selinux, ndc before we are ready to login in most circumstances. Do that get a login prompt, then start everything after we are logged in. There is no reason that cups should start before a login prompt.
As always just my way, not necessarily the right way.
Jon
On 9/13/07, Colin Walters walters@redhat.com wrote:
Some of the stuff starting here doesn't make sense outside of a server also...autofs, iscsi etc. We've been just killing that stuff by default for the desktop spin.
autofs..... let's talk about autofs for a minute.
I've got a home network with a centralized network storage home appliance aimed at home network being used for digital photos.
I've got a wife who uses picasa to manage that digital photo collection. Picasa specifically because picasa integrates with blogger and kodak's easy share gallery service which we are paying the yearly fee for.
I've got her computer setup to use autofs to see the cifs share from the network storage.
Her usage patterns are pretty much dead on target for "home desktop." Picasa isn't going away until f-spot grows some brains concerning integration with Kodak's easy share gallery service. I'm not suggestioning that using autofs is the smartest thing to deal with this situation. How would you deal with it in an autofs-less setup using a home network storage location that must work well with picasa?
-jef
On 9/13/07, Jeff Spaleta jspaleta@gmail.com wrote:
Her usage patterns are pretty much dead on target for "home desktop." Picasa isn't going away until f-spot grows some brains concerning integration with Kodak's easy share gallery service. I'm not suggestioning that using autofs is the smartest thing to deal with this situation. How would you deal with it in an autofs-less setup using a home network storage location that must work well with picasa?
Doesn't gnomevfs support cifs? I haven't tried though, honestly.
But in any case, my opinion on most network file systems is they'd be better replaced by rsync+cron possibly +inotify trigger.
On 9/13/07, Colin Walters walters@redhat.com wrote:
On 9/13/07, Jeff Spaleta jspaleta@gmail.com wrote:
Her usage patterns are pretty much dead on target for "home desktop." Picasa isn't going away until f-spot grows some brains concerning integration with Kodak's easy share gallery service. I'm not suggestioning that using autofs is the smartest thing to deal with this situation. How would you deal with it in an autofs-less setup using a home network storage location that must work well with picasa?
Doesn't gnomevfs support cifs? I haven't tried though, honestly.
But in any case, my opinion on most network file systems is they'd be better replaced by rsync+cron possibly +inotify trigger.
okay I just threw up a little in my mouth reading this.
That might work for a single user, but what about a family of users that want to share photos? If anything I would suggest a webdav enabled svn repo than rsync+cron. Drag and drop data, instant revision control. With some ldap and apache magic you can get user privileges refined as well.
Jon
On 9/13/07, Jon Nettleton jon.nettleton@gmail.com wrote:
That might work for a single user, but what about a family of users that want to share photos? If anything I would suggest a webdav enabled svn repo than rsync+cron. Drag and drop data, instant revision control. With some ldap and apache magic you can get user privileges refined as well.
maybe you missed my point. I'm not talking about a central file server that can have mature ldap and apache implementation. This isn't a small business network, with central management. This is a home network that has maybe on average 3 personal computers in use on the network. I'm talking about smb/cifs enabled "bricks" you go to a retail store to purchase then plug into your home network and they are expected to act like a windows file share that can be accessed from each of those home computers.
-jef
On 9/13/07, Jeff Spaleta jspaleta@gmail.com wrote:
On 9/13/07, Jon Nettleton jon.nettleton@gmail.com wrote:
That might work for a single user, but what about a family of users that want to share photos? If anything I would suggest a webdav enabled svn repo than rsync+cron. Drag and drop data, instant revision control. With some ldap and apache magic you can get user privileges refined as well.
maybe you missed my point. I'm not talking about a central file server that can have mature ldap and apache implementation. This isn't a small business network, with central management. This is a home network that has maybe on average 3 personal computers in use on the network. I'm talking about smb/cifs enabled "bricks" you go to a retail store to purchase then plug into your home network and they are expected to act like a windows file share that can be accessed from each of those home computers.
Oh I understand. That is what you get now, but another year or so you will get what I am describing. It all completely makes sense as an evolutionary step.
I am not really sure why everyone hates autofs so much. I am always looking for something better, but for general purpose file sharing it just works.
Jon
On 9/13/07, Jon Nettleton jon.nettleton@gmail.com wrote:
That might work for a single user, but what about a family of users that want to share photos? If anything I would suggest a webdav enabled svn repo than rsync+cron. Drag and drop data, instant revision control. With some ldap and apache magic you can get user privileges refined as well.
Right - which gets to my point which is that in very few situations do you actually want a remote filesystem. For backing up photos, you actually don't want to support permanent delete for example, or at least it should be very hard to do. Your svn repository would be like that.
But to go back to why I think autofs/iscsi and other kernel-mounted filesystems are a bad idea for the desktop is because you need to design for the laptop case, and my experience with all kernel-mounted filesystems and laptops has been uninterruptible processes hung on IO after you disconnect from the network. By putting things in user space you avoid this insanity, and it's a heck of a lot simpler.
I'm sure there are situations in which kernel-mounted NFS is appropriate, but it's one of those technologies I go out of my way to avoid because there is almost always a better way.
On 9/14/07, Colin Walters walters@redhat.com wrote:
On 9/13/07, Jon Nettleton jon.nettleton@gmail.com wrote:
That might work for a single user, but what about a family of users that want to share photos? If anything I would suggest a webdav enabled svn repo than rsync+cron. Drag and drop data, instant revision control. With some ldap and apache magic you can get user privileges refined as well.
Right - which gets to my point which is that in very few situations do you actually want a remote filesystem. For backing up photos, you actually don't want to support permanent delete for example, or at least it should be very hard to do. Your svn repository would be like that.
But to go back to why I think autofs/iscsi and other kernel-mounted filesystems are a bad idea for the desktop is because you need to design for the laptop case, and my experience with all kernel-mounted filesystems and laptops has been uninterruptible processes hung on IO after you disconnect from the network. By putting things in user space you avoid this insanity, and it's a heck of a lot simpler.
I'm sure there are situations in which kernel-mounted NFS is appropriate, but it's one of those technologies I go out of my way to avoid because there is almost always a better way.
a lot of this will also be alleviated once we get a proper location manager. I have a semi-working one right now based on an overlay fs on top of /etc. Each location is a different subversion branch and only changed files get stored in the overlay. It also exposes the location through dbus for a user-space app. It is a long way from reliable and finished but I am happy with the design so far.
Jon
On 9/13/07, Colin Walters walters@redhat.com wrote:
But in any case, my opinion on most network file systems is they'd be better replaced by rsync+cron possibly +inotify trigger.
rsyncing 500 Gig networkable appliances to where exactly? ... like these things: http://www.lacie.com/products/product.htm?pid=10844
Network-capable large capacity harddrives marketted to home users are a reality. I think I can even get them a Sam's Club and Walmart now. People actually use these things...over home networks... not kidding.
I know that gnome-vfs deals with cifs... but picasa doesn't talk gnome-vfs as far as I know. if you can tell me how to get picasa or other non-gnome applications to see a cifs connection managed by gnome-vfs.. i might buy you a beer.
-jef"really really really would like to drop the use of autofs"spaleta
On 9/13/07, Jeff Spaleta jspaleta@gmail.com wrote:
On 9/13/07, Colin Walters walters@redhat.com wrote:
But in any case, my opinion on most network file systems is they'd be better replaced by rsync+cron possibly +inotify trigger.
rsyncing 500 Gig networkable appliances to where exactly? ... like these things: http://www.lacie.com/products/product.htm?pid=10844
Network-capable large capacity harddrives marketted to home users are a reality. I think I can even get them a Sam's Club and Walmart now. People actually use these things...over home networks... not kidding.
I know that gnome-vfs deals with cifs... but picasa doesn't talk gnome-vfs as far as I know. if you can tell me how to get picasa or other non-gnome applications to see a cifs connection managed by gnome-vfs.. i might buy you a beer.
-jef"really really really would like to drop the use of autofs"spaleta
you can do all of this with fuse. When the gvfs2 comes out that will all be included for free.
Jon
On 9/13/07, Jon Nettleton jon.nettleton@gmail.com wrote:
you can do all of this with fuse. When the gvfs2 comes out that will all be included for free.
That's a fuse plugin correct? Uhm... fuse doesn't work out of the box in Fedora currently. I _think_ we still ship fuse in such a way that you have to manually take some action add users to the fuse group for users that get to use fuse. Even if gvfs2 is the magic glue that I need to connect non-gnome apps to gnomevfs, we'll have to do something to make fuse work out of the box if we are going to rely on fuse to be the glue moving forward.
-jef"when will now be then?... soon!"spaleta
On 9/13/07, Jeff Spaleta jspaleta@gmail.com wrote:
On 9/13/07, Jon Nettleton jon.nettleton@gmail.com wrote:
you can do all of this with fuse. When the gvfs2 comes out that will all be included for free.
That's a fuse plugin correct? Uhm... fuse doesn't work out of the box in Fedora currently. I _think_ we still ship fuse in such a way that you have to manually take some action add users to the fuse group for users that get to use fuse. Even if gvfs2 is the magic glue that I need to connect non-gnome apps to gnomevfs, we'll have to do something to make fuse work out of the box if we are going to rely on fuse to be the glue moving forward.
hmmm works for me out of the box. I am actually working on a couple of different filesystems right now that are all based on fuse. Fedora doesn't ship with any plugins by default, but the fuse kernel module is there. Is it because the kernel module isn't loaded by default? I load mine in /etc/sysconfig/modules
I definitely think we need a gui to add more functionality there. I have remove cpuspeed from boot and the acpi modules from rc.sysinit and replaced them with scripts in that directory. It seems a shame that the infrastructure was added and nothing changed to take advantage of it.
Jon
Jon Nettleton (jon.nettleton@gmail.com) said:
I definitely think we need a gui to add more functionality there. I have remove cpuspeed from boot and the acpi modules from rc.sysinit and replaced them with scripts in that directory. It seems a shame that the infrastructure was added and nothing changed to take advantage of it.
That's because it's a crap infrastructure. :)
Seriously, acpi modules should be autoloaded based on DMI and ACPI table matching (almost done), and the governors should probably be built-in (as userspace is generally wrong.)
Bill
On 9/13/07, Bill Nottingham notting@redhat.com wrote:
Jon Nettleton (jon.nettleton@gmail.com) said:
I definitely think we need a gui to add more functionality there. I have remove cpuspeed from boot and the acpi modules from rc.sysinit and replaced them with scripts in that directory. It seems a shame that the infrastructure was added and nothing changed to take advantage of it.
That's because it's a crap infrastructure. :)
Seriously, acpi modules should be autoloaded based on DMI and ACPI table matching (almost done), and the governors should probably be built-in (as userspace is generally wrong.)
All that sounds great. As with everything I have said before all my stuff I have worked on is right here and right now. My intention is to stop the bleeding of Fedora becoming an under-used under-appreciated desktop distribution by making small effective changes now.
Once we get more people excited about Fedora Desktop it will knock the ball out of the park when we implement the more refined infra-structure pieces.
Jon
Jon Nettleton (jon.nettleton@gmail.com) said:
That's because it's a crap infrastructure. :)
Seriously, acpi modules should be autoloaded based on DMI and ACPI table matching (almost done), and the governors should probably be built-in (as userspace is generally wrong.)
All that sounds great. As with everything I have said before all my stuff I have worked on is right here and right now. My intention is to stop the bleeding of Fedora becoming an under-used under-appreciated desktop distribution by making small effective changes now.
Sure. I just don't see what you gain by replacing a shell script that loads modules... with a different shell script.
Bill
On 9/14/07, Bill Nottingham notting@redhat.com wrote:
Jon Nettleton (jon.nettleton@gmail.com) said:
That's because it's a crap infrastructure. :)
Seriously, acpi modules should be autoloaded based on DMI and ACPI table matching (almost done), and the governors should probably be built-in (as userspace is generally wrong.)
All that sounds great. As with everything I have said before all my stuff I have worked on is right here and right now. My intention is to stop the bleeding of Fedora becoming an under-used under-appreciated desktop distribution by making small effective changes now.
Sure. I just don't see what you gain by replacing a shell script that loads modules... with a different shell script.
I think the big win with changes like this is consistency. Right now there are 5 differents methods for loading modules on startup.
1) initrd. Of course this is necessary, but mkinitrd it doesn't respect changes made to /etc/modprobe.d/blacklist.
2) Traditional modprobe.conf, but now we have added /etc/modprobe.d/*
3) /etc/rc.modules
4) some modules right in /etc/rc.sysinit
5) and the new guy /etc/sysconfig/modules
One of the goals of a small change like this is to start getting ready for larger changes by having an organized system. If we don't like /etc/sysconfig/modules then let's get rid of it. What we have now just seems disjoint and confusing.
Jon
Jon Nettleton (jon.nettleton@gmail.com) said:
Sure. I just don't see what you gain by replacing a shell script that loads modules... with a different shell script.
I think the big win with changes like this is consistency. Right now there are 5 differents methods for loading modules on startup.
- initrd. Of course this is necessary, but mkinitrd it doesn't
respect changes made to /etc/modprobe.d/blacklist.
Really? modprobe --show-depends pulls in things from the blacklist? Sounds like a bug.
- /etc/rc.modules
Should probably be nuked - it's time for it to go.
- some modules right in /etc/rc.sysinit
Already removed in CVS.
- and the new guy /etc/sysconfig/modules
Not that new. It's 2 1/2 years old.
Bill
Jon Nettleton (jon.nettleton@gmail.com) said:
One of the goals of a small change like this is to start getting ready for larger changes by having an organized system. If we don't like /etc/sysconfig/modules then let's get rid of it. What we have now just seems disjoint and confusing.
To elaborate, we don't like it *as a distribution mechanism*. It's fine to have something like that for local customization. But, realistically, if people need modules loaded for their hardware on bootup that aren't getting automatically loaded, it's a *bug* that needs to be fixed.
Bill
On Thu, Sep 13, 2007 at 11:01:38PM -0400, Bill Nottingham wrote:
That's because it's a crap infrastructure. :)
Seriously, acpi modules should be autoloaded based on DMI and ACPI table matching (almost done), and the governors should probably be built-in (as userspace is generally wrong.)
The problem arises with older (and some crappy recent) hardware. We can't always just use on-demand. Which is why in some cases we still use the userspace daemon. (VIA CPUs are notoriously bad with ondemand up until their latest generation).
Dave
On 9/13/07, Jon Nettleton jon.nettleton@gmail.com wrote:
hmmm works for me out of the box. I am actually working on a couple of different filesystems right now that are all based on fuse.
I love being wrong. I'll dig back into this.
-jef
On Thu, 2007-09-13 at 22:50 -0400, Jon Nettleton wrote:
On 9/13/07, Jeff Spaleta jspaleta@gmail.com wrote:
On 9/13/07, Jon Nettleton jon.nettleton@gmail.com wrote:
you can do all of this with fuse. When the gvfs2 comes out that will all be included for free.
That's a fuse plugin correct? Uhm... fuse doesn't work out of the box in Fedora currently. I _think_ we still ship fuse in such a way that you have to manually take some action add users to the fuse group for users that get to use fuse. Even if gvfs2 is the magic glue that I need to connect non-gnome apps to gnomevfs, we'll have to do something to make fuse work out of the box if we are going to rely on fuse to be the glue moving forward.
hmmm works for me out of the box. I am actually working on a couple of different filesystems right now that are all based on fuse. Fedora doesn't ship with any plugins by default, but the fuse kernel module is there. Is it because the kernel module isn't loaded by default? I load mine in /etc/sysconfig/modules
Whats required is that you have to add your user to the fuse group.
On Thu, 2007-09-13 at 18:35 -0800, Jeff Spaleta wrote:
On 9/13/07, Jon Nettleton jon.nettleton@gmail.com wrote:
you can do all of this with fuse. When the gvfs2 comes out that will all be included for free.
That's a fuse plugin correct? Uhm... fuse doesn't work out of the box in Fedora currently. I _think_ we still ship fuse in such a way that you have to manually take some action add users to the fuse group for users that get to use fuse.
Yes we do. And this is totally stupid and will cause pain in the future when all sorts of features (like gvfs) start using fuse. I have no idea why this was done, but it has to be fixed.
On 14.09.2007 10:17, Alexander Larsson wrote:
On Thu, 2007-09-13 at 18:35 -0800, Jeff Spaleta wrote:
On 9/13/07, Jon Nettleton jon.nettleton@gmail.com wrote:
you can do all of this with fuse. When the gvfs2 comes out that will all be included for free.
That's a fuse plugin correct? Uhm... fuse doesn't work out of the box in Fedora currently. I _think_ we still ship fuse in such a way that you have to manually take some action add users to the fuse group for users that get to use fuse.
Yes we do. And this is totally stupid and will cause pain in the future when all sorts of features (like gvfs) start using fuse. I have no idea why this was done, but it has to be fixed.
Thx for your kind words to your fellow Fedora developers, much appreciated ;-) (¹)
I decided that -- but not alone. In fact IIRC I was urged by lots of high-rank-Fedora-developers (including jeremy and someone from the security team IIRC) to *not* ship fuse as a suid-binary for everyone, as back then (in the early days when fuse hit the kernel) it was highly unclear if the fuse userspace tools were safe enough.
If that has changed: sure, let's get rid of this extra burden with adding the user to a special group. But that's up to the current maintainer.
CU knurd
(¹) -- No, I'm don't have a problem with calling a decision of mine "totally stupid" (I sometimes do myself). But I think it's not helpful when done in public.
IOW: This IMHO is just another occurrence that confirms by impression that "the tone on the fedora lists IMHO gets worse and worse" (²) -- that's IMHO bad as it might be deterring to new developers or lurkers on the list that might fear hard words more then we do.
/me always wonders if people on a party or a conference would go to the podium and say "foo is totally stupid" if the chance that the one that is responsible for "foo" is in the auditorium
(²)http://thorstenl.blogspot.com/2007/07/evolution-or-growth-of-fedora.html
On 9/14/07, Thorsten Leemhuis fedora@leemhuis.info wrote:
(¹) -- No, I'm don't have a problem with calling a decision of mine "totally stupid" (I sometimes do myself). But I think it's not helpful when done in public.
IOW: This IMHO is just another occurrence that confirms by impression that "the tone on the fedora lists IMHO gets worse and worse" (²) -- that's IMHO bad as it might be deterring to new developers or lurkers on the list that might fear hard words more then we do.
I think i this case we can put the blame completely on Jeremy. So its perfectly fair to say that Jeremy was totally stupid.... and you were just an innocent victim of his masterful power of persuasion. Speaking of which, I'm going to be pitching a comedy spin-off of Heros to NBC, which has stories for not-so-dramatic superpower storylines with Jeremy's badly applied superhuman power of persuasion will be the season opener!
/me always wonders if people on a party or a conference would go to the podium and say "foo is totally stupid" if the chance that the one that is responsible for "foo" is in the auditorium
Actually a statement like that to open up a conference presentation is a great way to have the audience pay attention. That would definitely be a memorable presentation: "Hey did you see the youtube video of Jef's presentation where he totally went crazy and called the xrandr developers idiots?" "Yeah!" "Dude, what an jackass." "Yeah" "He was like foaming at the mouth and stuff." "Didn't Jef make that video in his parent's basement?" "Looks like it" "Jackass"
I think people on the lists communicate by and large exactly how they would communicate in any established small working group settings... say for example the 4th lab group assignment in a college course. Not the first assignment, at the beginning of the class when people don't really know each other yet. But the fourth assignment, after the group members have pretty much gained an intuitive feel for the personality quirks of the rest of the group. Except on the lists, you're interacting with people you haven't actually had enough face-to-face time with to get an accurate intuitive feel for them so its much easier to cross the line from passionated impersonal discussion into personal offense without ever knowing you crossed it.
-jef
On 14.09.2007 18:36, Jeff Spaleta wrote:
On 9/14/07, Thorsten Leemhuis fedora@leemhuis.info wrote:
(¹) -- No, I'm don't have a problem with calling a decision of mine "totally stupid" (I sometimes do myself). But I think it's not helpful when done in public. IOW: This IMHO is just another occurrence that confirms by impression that "the tone on the fedora lists IMHO gets worse and worse" (²) -- that's IMHO bad as it might be deterring to new developers or lurkers on the list that might fear hard words more then we do.
I think i this case we can put the blame completely on Jeremy. So its perfectly fair to say that Jeremy was totally stupid.... and you were just an innocent victim of his masterful power of persuasion.
It wasn't his decision alon and I backed the idea ;-)
When I handed over the package to someone else I even said explicit: don't remove that stuff!
But as I said: I can live with being called "totally stupid" -- I'm around long enough and got used to it.
[...]
/me always wonders if people on a party or a conference would go to the podium and say "foo is totally stupid" if the chance that the one that is responsible for "foo" is in the auditorium
Actually a statement like that to open up a conference presentation is a great way to have the audience pay attention. [...]
Hehe, yeah, I suppose it would.
I think people on the lists communicate by and large exactly how they would communicate in any established small working group settings... say for example the 4th lab group assignment in a college course. Not the first assignment, at the beginning of the class when people don't really know each other yet. But the fourth assignment, after the group members have pretty much gained an intuitive feel for the personality quirks of the rest of the group. Except on the lists, you're interacting with people you haven't actually had enough face-to-face time with to get an accurate intuitive feel for them so its much easier to cross the line from passionated impersonal discussion into personal offense without ever knowing you crossed it.
Fully agreed. I'd even would like to add something: In this "college course" (aka this list) there are constantly new people watching from the side if they should join the never-ending-course. And that's what we want IMHO: join us, help us. But if you would look for a area to jum in and watch a course where people are rude or unfriendly to each other without need: would you join it or look out for another (friendlier) course?
Cu knurd
On Fri, 2007-09-14 at 10:56 +0200, Thorsten Leemhuis wrote:
On 14.09.2007 10:17, Alexander Larsson wrote:
That's a fuse plugin correct? Uhm... fuse doesn't work out of the box in Fedora currently. I _think_ we still ship fuse in such a way that you have to manually take some action add users to the fuse group for users that get to use fuse.
Yes we do. And this is totally stupid and will cause pain in the future when all sorts of features (like gvfs) start using fuse. I have no idea why this was done, but it has to be fixed.
Thx for your kind words to your fellow Fedora developers, much appreciated ;-) (¹)
I decided that -- but not alone. In fact IIRC I was urged by lots of high-rank-Fedora-developers (including jeremy and someone from the security team IIRC) to *not* ship fuse as a suid-binary for everyone, as back then (in the early days when fuse hit the kernel) it was highly unclear if the fuse userspace tools were safe enough.
If that has changed: sure, let's get rid of this extra burden with adding the user to a special group. But that's up to the current maintainer.
If its not safe then wouldn't a better solution be to fix it or not ship/install it.
Making every user have to be added to the fuse group means:
1) Its not useable by default, meaning extra work for all users, and features mystically not working before some magic sysadmin incantation. (We could make it "easy" to detect this and add users to this group, but then again, why have the group?)
2) When important things in the desktop start requiring fuse everyone will be in the fuse group anyway, meaning any security is lost. (One could say this only happens on "desktop" machines, but if you don't trust fuse userspace on your server, just don't install it there.)
I agree that stupid was a bad word, and I don't mean to flame anyone in particular. I just think that this decision has no real value security-wise, and it will be quite negative when things actually start using fuse. Perhaps it was the right choice early on in the life of fuse, but i don't think it makes sense by now.
On 18.09.2007 10:35, Alexander Larsson wrote:
On Fri, 2007-09-14 at 10:56 +0200, Thorsten Leemhuis wrote:
On 14.09.2007 10:17, Alexander Larsson wrote:
That's a fuse plugin correct? Uhm... fuse doesn't work out of the box in Fedora currently. I _think_ we still ship fuse in such a way that you have to manually take some action add users to the fuse group for users that get to use fuse.
Yes we do. And this is totally stupid and will cause pain in the future when all sorts of features (like gvfs) start using fuse. I have no idea why this was done, but it has to be fixed.
[...] I decided that -- but not alone. In fact IIRC I was urged by lots of high-rank-Fedora-developers (including jeremy and someone from the security team IIRC) to *not* ship fuse as a suid-binary for everyone, as back then (in the early days when fuse hit the kernel) it was highly unclear if the fuse userspace tools were safe enough.
If that has changed: sure, let's get rid of this extra burden with adding the user to a special group. But that's up to the current maintainer.
If its not safe then wouldn't a better solution be to fix it or not ship/install it.
In a perfect world: agreed. But we don't live in one afaics :-/
Fedora is a community distribution, and we IMHO can't put the burden on packagers to high, as there otherwise won't be much of a community anymore that takes care of Fedora. "Fix it" would be way to high burden, as lot's of the Fedora maintainers have only basic or next-to-none programming skills -- nevertheless they do lots of work for Fedora, and that's a good thing for Fedora. In "my perfect Fedora world" they hopefully take over those "easy" tasks from people with more skills, so the latter have more time for other stuff that requires their skills.
Not shipping something or waiting forever for someone with enough skills to show up to fix it is not always a real option either afaics, as that might take so long, that users get disappointed and switch to another distro, which is also what we don't want.
Making every user have to be added to the fuse group means:
- Its not useable by default, meaning extra work for all users, and features mystically not working before some magic sysadmin incantation. (We could make it "easy" to detect this and add users to this group, but then again, why have the group?)
Fully agreed in general. But for fuse it was a compromise back then and IMHO an acceptable one.
<side note>I *sometimes* wonder if rpm/Fedora should have a (rarely used!) way for packagers to notify the sysadmin with stuff like "hey, you installed mysql, but you need to set a password for the database" (the init scripts from mysqld do exactly that ATM, but one can easily miss that informations). Similar stuff could be used for fuse for the problem at hand.</side note>
- When important things in the desktop start requiring fuse everyone will be in the fuse group anyway, meaning any security is lost. (One could say this only happens on "desktop" machines, but if you don't trust fuse userspace on your server, just don't install it there.)
No offense, but well, if "important things in the desktop start requiring fuse" I suppose people programming that stuff first make sure it's safe and wise to use fuse, as it might backfire to their apps if fuse is unsafe.
It's likely nothing more then asking the Fedora developers "can we get rid of the add-to-a-specific-group stuff for fuse over the next few months? I want to use fuse for important things in the desktop" *before* starting to really depend on fuse.
BTW, thanks for working on gvfs2 -- looks promising.
[...] I just think that this decision has no real value security-wise, and it will be quite negative when things actually start using fuse. Perhaps it was the right choice early on in the life of fuse,
Agreed.
but i don't think it makes sense by now.
Might be the case. But as I said: I'm not the maintainer anymore. Talk to him about it (and maybe those core-fedora developers that vetoed SUID-root fuse back then).
CU knurd
On Ter, 2007-09-18 at 11:34 +0200, Thorsten Leemhuis wrote:
Might be the case. But as I said: I'm not the maintainer anymore. Talk to him about it (and maybe those core-fedora developers that vetoed SUID-root fuse back then).
Somewhat uninformed opinion but: can't D-Bus system activation with its suid helper be used to do a fuse mount thus making the fuse binaries not needing to have any extraordinary bit set? There could be a D-Bus policy file that admins could edit and by default only console (local) users should be allowed to use this "mount service".
2 cents worth
Rui
On Tue, 2007-09-18 at 11:33 +0100, Rui Tiago Cação Matos wrote:
On Ter, 2007-09-18 at 11:34 +0200, Thorsten Leemhuis wrote:
Might be the case. But as I said: I'm not the maintainer anymore. Talk to him about it (and maybe those core-fedora developers that vetoed SUID-root fuse back then).
Somewhat uninformed opinion but: can't D-Bus system activation with its suid helper be used to do a fuse mount thus making the fuse binaries not needing to have any extraordinary bit set? There could be a D-Bus policy file that admins could edit and by default only console (local) users should be allowed to use this "mount service".
What your proposing is a quite a large change in how fuse works. I don't quite see the advantage of doing it just to use a different setuid helper.
On 18.09.2007 12:33, Rui Tiago Cação Matos wrote:
On Ter, 2007-09-18 at 11:34 +0200, Thorsten Leemhuis wrote:
Might be the case. But as I said: I'm not the maintainer anymore. Talk to him about it (and maybe those core-fedora developers that vetoed SUID-root fuse back then).
Somewhat uninformed opinion but: can't D-Bus system activation with its suid helper be used to do a fuse mount thus making the fuse binaries not needing to have any extraordinary bit set? There could be a D-Bus policy file that admins could edit and by default only console (local) users should be allowed to use this "mount service".
I don't think it would make much of a difference in the end and it would likely be way more complicated.
CU knurd
On Tue, 2007-09-18 at 11:34 +0200, Thorsten Leemhuis wrote:
On 18.09.2007 10:35, Alexander Larsson wrote:
- When important things in the desktop start requiring fuse everyone will be in the fuse group anyway, meaning any security is lost. (One could say this only happens on "desktop" machines, but if you don't trust fuse userspace on your server, just don't install it there.)
No offense, but well, if "important things in the desktop start requiring fuse" I suppose people programming that stuff first make sure it's safe and wise to use fuse, as it might backfire to their apps if fuse is unsafe.
I had no idea that Fedora was doing this to its fuse packaging when designing gvfs. I've looked into fuse a bit, and it seemed safe to me.
It's likely nothing more then asking the Fedora developers "can we get rid of the add-to-a-specific-group stuff for fuse over the next few months? I want to use fuse for important things in the desktop" *before* starting to really depend on fuse.
Yeah.
On Tue, 2007-09-18 at 10:35 +0200, Alexander Larsson wrote:
On Fri, 2007-09-14 at 10:56 +0200, Thorsten Leemhuis wrote:
On 14.09.2007 10:17, Alexander Larsson wrote:
That's a fuse plugin correct? Uhm... fuse doesn't work out of the box in Fedora currently. I _think_ we still ship fuse in such a way that you have to manually take some action add users to the fuse group for users that get to use fuse.
Yes we do. And this is totally stupid and will cause pain in the future when all sorts of features (like gvfs) start using fuse. I have no idea why this was done, but it has to be fixed.
Thx for your kind words to your fellow Fedora developers, much appreciated ;-) (¹)
I decided that -- but not alone. In fact IIRC I was urged by lots of high-rank-Fedora-developers (including jeremy and someone from the security team IIRC) to *not* ship fuse as a suid-binary for everyone, as back then (in the early days when fuse hit the kernel) it was highly unclear if the fuse userspace tools were safe enough.
If that has changed: sure, let's get rid of this extra burden with adding the user to a special group. But that's up to the current maintainer.
If its not safe then wouldn't a better solution be to fix it or not ship/install it.
Making sure that things are safe is definitely the right thing to do. suid but only group executable is purely a "start to get it in while not making things less secure by default"
I agree that stupid was a bad word, and I don't mean to flame anyone in particular. I just think that this decision has no real value security-wise, and it will be quite negative when things actually start using fuse. Perhaps it was the right choice early on in the life of fuse, but i don't think it makes sense by now.
It was nothing more than a "someone needs to sit down and really audit fuse". And probably ensuring that we have reasonable SELinux policy around it as well. If someone is willing to do that so that we can feel comfortable making fuse available suid and that we're not then opening up various holes on the system, then let's do it.
But until someone actually does that audit, it seems a bit premature and risky to actually have the fuse bits executable by everyone.
Jeremy
On 18.09.2007 16:28, Jeremy Katz wrote:
On Tue, 2007-09-18 at 10:35 +0200, Alexander Larsson wrote:
On Fri, 2007-09-14 at 10:56 +0200, Thorsten Leemhuis wrote:
On 14.09.2007 10:17, Alexander Larsson wrote:
That's a fuse plugin correct? Uhm... fuse doesn't work out of the box in Fedora currently. I _think_ we still ship fuse in such a way that you have to manually take some action add users to the fuse group for users that get to use fuse.
Yes we do. And this is totally stupid and will cause pain in the future when all sorts of features (like gvfs) start using fuse. I have no idea why this was done, but it has to be fixed.
Thx for your kind words to your fellow Fedora developers, much appreciated ;-) (¹) I decided that -- but not alone. In fact IIRC I was urged by lots of high-rank-Fedora-developers (including jeremy and someone from the security team IIRC) to *not* ship fuse as a suid-binary for everyone, as back then (in the early days when fuse hit the kernel) it was highly unclear if the fuse userspace tools were safe enough. If that has changed: sure, let's get rid of this extra burden with adding the user to a special group. But that's up to the current maintainer.
If its not safe then wouldn't a better solution be to fix it or not ship/install it.
Making sure that things are safe is definitely the right thing to do. suid but only group executable is purely a "start to get it in while not making things less secure by default"
While at it maybe someone can explain something about fuse which I never understood:
I got a new laptop three months ago. It came with Windows and thus a NTFS partition which I only made smaller, but did not remove -- /dev/sda3 to be precise:
$ ls -l /dev/sda3 brw-r----- 1 root disk 8, 3 14. Sep 16:10 /dev/sda3
Okay, it's only read-writable for root and readable for "disk" -- a group which I'm not part of:
$ groups thl fuse
Thus I'm not even able to read from it:
$ dd if=/dev/sda3 bs=512K count=1 | strings dd: opening `/dev/sda3': Permission denied
Life sucks, but that's how things are supposed to be in linux/unix land as far as I know. But well, for fuse there seem to exist different rules:
$ mkdir ntfs $ /sbin/mount.ntfs-3g /dev/sda3 ntfs/ $ touch ntfs/foo $ ls -l ntfs/foo -rwxrwxrwx 1 thl thl 0 18. Sep 19:27 ntfs/foo
Which brings me to my questions: Can somebody please explain why the above it working? Does it mean that if I write my own malicious fuse.ext3 userspace driver that I can mount each and every block-device on my system and read or modify the files on it (all by using fuse)? What if there is a small error in mount.ntfs-3g somewhere -- could it be abused to destroy a partition on my system while being a ordinary user?
Just wondering -- maybe I just don't understand the concept of fuse (maybe I'm getting to old for this...). Or maybe there is a bug somewhere in our packages and that above scenario works? Or a side-effect of our "add to fuse-group strategy?
Cu knurd
On Tue, 2007-09-18 at 19:41 +0200, Thorsten Leemhuis wrote:
Thus I'm not even able to read from it:
$ dd if=/dev/sda3 bs=512K count=1 | strings dd: opening `/dev/sda3': Permission denied
Life sucks, but that's how things are supposed to be in linux/unix land as far as I know. But well, for fuse there seem to exist different rules:
$ mkdir ntfs $ /sbin/mount.ntfs-3g /dev/sda3 ntfs/ $ touch ntfs/foo $ ls -l ntfs/foo -rwxrwxrwx 1 thl thl 0 18. Sep 19:27 ntfs/foo
Which brings me to my questions: Can somebody please explain why the above it working? Does it mean that if I write my own malicious fuse.ext3 userspace driver that I can mount each and every block-device on my system and read or modify the files on it (all by using fuse)? What if there is a small error in mount.ntfs-3g somewhere -- could it be abused to destroy a partition on my system while being a ordinary user?
Thats quite weird. The way I undestand fuse is that you run the filesystem as your user, and then that filesystem (via libfuse) spawns fusermount to open the fuse device and attach to the mountpoint. fusermount then passes the fd to the fuse device back the the filesystem process (via a socket) which then handles all the requests.
Reading the data source for the filesystem (if there is any) is only done by the filesystem process, not by the setuid fusermount helper, so it should not be able to read /dev/sda3.
Is /sbin/mount.ntfs-3g setuid perhaps? Can you verify the uid/euid of the ntfs mount process?
On 19.09.2007 09:09, Alexander Larsson wrote:
On Tue, 2007-09-18 at 19:41 +0200, Thorsten Leemhuis wrote:
Thus I'm not even able to read from it:
$ dd if=/dev/sda3 bs=512K count=1 | strings dd: opening `/dev/sda3': Permission denied
Life sucks, but that's how things are supposed to be in linux/unix land as far as I know. But well, for fuse there seem to exist different rules:
$ mkdir ntfs $ /sbin/mount.ntfs-3g /dev/sda3 ntfs/ $ touch ntfs/foo $ ls -l ntfs/foo -rwxrwxrwx 1 thl thl 0 18. Sep 19:27 ntfs/foo
Which brings me to my questions: Can somebody please explain why the above it working? Does it mean that if I write my own malicious fuse.ext3 userspace driver that I can mount each and every block-device on my system and read or modify the files on it (all by using fuse)? What if there is a small error in mount.ntfs-3g somewhere -- could it be abused to destroy a partition on my system while being a ordinary user?
Thats quite weird. [...]
Agreed. But I got the impression that how some users expect it to work.
Is /sbin/mount.ntfs-3g setuid perhaps?
Yes:
$ ls -l /sbin/mount.ntfs-3g -rwsr-xr-- 1 root fuse 40528 26. Aug 16:50 /sbin/mount.ntfs-3g
CU knurd
On Wed, 2007-09-19 at 09:38 +0200, Thorsten Leemhuis wrote:
On 19.09.2007 09:09, Alexander Larsson wrote:
On Tue, 2007-09-18 at 19:41 +0200, Thorsten Leemhuis wrote:
Thus I'm not even able to read from it:
$ dd if=/dev/sda3 bs=512K count=1 | strings dd: opening `/dev/sda3': Permission denied
Life sucks, but that's how things are supposed to be in linux/unix land as far as I know. But well, for fuse there seem to exist different rules:
$ mkdir ntfs $ /sbin/mount.ntfs-3g /dev/sda3 ntfs/ $ touch ntfs/foo $ ls -l ntfs/foo -rwxrwxrwx 1 thl thl 0 18. Sep 19:27 ntfs/foo
Which brings me to my questions: Can somebody please explain why the above it working? Does it mean that if I write my own malicious fuse.ext3 userspace driver that I can mount each and every block-device on my system and read or modify the files on it (all by using fuse)? What if there is a small error in mount.ntfs-3g somewhere -- could it be abused to destroy a partition on my system while being a ordinary user?
Thats quite weird. [...]
Agreed. But I got the impression that how some users expect it to work.
Is /sbin/mount.ntfs-3g setuid perhaps?
Yes:
$ ls -l /sbin/mount.ntfs-3g -rwsr-xr-- 1 root fuse 40528 26. Aug 16:50 /sbin/mount.ntfs-3g
Oh. That seems like a bad idea to me. If this drops privs after opening the device I think you can attach to the process using e.g. gdb and call any read() operation on the device. If might even mean (with some creative exploits) that any fuse group user can read any block on any disk.
I think the "fuse" group thing is a bad idea for /sbin/fusermount, but for something like this it might make sense. Although its probably better to not have mount.ntfs-3g setuid and just force the user to be in the "disk" group, as that makes it more obvious what this is about.
On 19.09.2007 09:51, Alexander Larsson wrote:
On Wed, 2007-09-19 at 09:38 +0200, Thorsten Leemhuis wrote:
On 19.09.2007 09:09, Alexander Larsson wrote:
On Tue, 2007-09-18 at 19:41 +0200, Thorsten Leemhuis wrote:
Thus I'm not even able to read from it: $ dd if=/dev/sda3 bs=512K count=1 | strings dd: opening `/dev/sda3': Permission denied Life sucks, but that's how things are supposed to be in linux/unix land as far as I know. But well, for fuse there seem to exist different rules: $ mkdir ntfs $ /sbin/mount.ntfs-3g /dev/sda3 ntfs/ $ touch ntfs/foo $ ls -l ntfs/foo -rwxrwxrwx 1 thl thl 0 18. Sep 19:27 ntfs/foo Which brings me to my questions: Can somebody please explain why the above it working? Does it mean that if I write my own malicious fuse.ext3 userspace driver that I can mount each and every block-device on my system and read or modify the files on it (all by using fuse)? What if there is a small error in mount.ntfs-3g somewhere -- could it be abused to destroy a partition on my system while being a ordinary user?
Thats quite weird. [...]
Agreed. But I got the impression that how some users expect it to work.
Is /sbin/mount.ntfs-3g setuid perhaps?
Yes: $ ls -l /sbin/mount.ntfs-3g -rwsr-xr-- 1 root fuse 40528 26. Aug 16:50 /sbin/mount.ntfs-3g
Oh. That seems like a bad idea to me.
+1
I tried to discuss the issue with spot (the ntfs-3g maintainer) in #fedora-devel but he was busy and he asked me to file a bug, which I just did:
https://bugzilla.redhat.com/show_bug.cgi?id=298651
Cu knurd
On Tue, 2007-09-18 at 19:41 +0200, Thorsten Leemhuis wrote:
I got a new laptop three months ago. It came with Windows and thus a NTFS partition which I only made smaller, but did not remove -- /dev/sda3 to be precise:
$ ls -l /dev/sda3 brw-r----- 1 root disk 8, 3 14. Sep 16:10 /dev/sda3
FWIW, just doing
$ gnome-mount -d /dev/sda3
or double-clicking the appropriate icon it in Nautilus is how it works in Fedora 8. You may need to go through a one-time-pain dialog to enter either your own or the root password.
[...]
Which brings me to my questions: Can somebody please explain why the above it working? Does it mean that if I write my own malicious fuse.ext3 userspace driver that I can mount each and every block-device on my system and read or modify the files on it (all by using fuse)?
Probably. Someone better fix fuse to not allow this.
David
desktop@lists.fedoraproject.org