Description of problem: I am not sure if this is really 'hal' but I am not sure what is this 'manager.c' which produces these messages: manager.c/982: mount_all: mounting /dev/sda1 mount: only root can mount /dev/sda1 on /media/scsidisk6 manager.c/982: mount_all: mounting /dev/sda2 mount: only root can mount /dev/sda2 on /media/scsidisk5 manager.c/982: mount_all: mounting /dev/sda3 mount: only root can mount /dev/sda3 on /media/scsidisk4 manager.c/982: mount_all: mounting /dev/sda6 mount: only root can mount /dev/sda6 on /media/scsidisk3 manager.c/982: mount_all: mounting /dev/sda7 mount: only root can mount /dev/sda7 on /media/scsidisk2 manager.c/982: mount_all: mounting /dev/sda8 mount: only root can mount /dev/sda8 on /media/scsidisk1 manager.c/982: mount_all: mounting /dev/sda9 mount: only root can mount /dev/sda9 on /media/scsidisk Very good! These are clearly marked 'noauto', and no other options, and there are __not supposed__ to be mounted and definitely that is the case for non-root. So why all this racket? Actually the fact that they get mounted when 'root' is loging to a desktop, and they have to be constantly unmounted, is a bug. Not a show-stopper but a getting on nerves inconvenience.
Reassigning to gnome-volume-manager and John P. > These are clearly marked 'noauto' Which are put in by fstab-sync from hal such that such entries aren't mounted at startup. This doesn't imply they shouldn't be mounted when a desktop session starts. Michal, I'm interested if you see any security issues with this? This, btw, can be disabled in the g-v-m capplet (Hat Menu->Applications->Preferences->Removable Storage) by disabling automounting all together. FYI there have been complaints upstream about this as well http://mail.gnome.org/archives/utopia-list/2004-September/msg00009.html so disabling might be an option; John? > Actually the fact that they get mounted when 'root' is > loging to a desktop, and they have to be constantly > unmounted, is a bug. Actually g-v-m unmounts all volumes mounted during the session on logout, but, OK, if your session dies they are not. Another thing is that it is discouraged to login to the GNOME desktop as root but that is another matter.
> Which are put in by fstab-sync from hal such that such entries aren't > mounted at startup. More precisely I edited them out from an insane garbage dumped into my /etc/fstab by fstab-sync. I cannot remove them entirely because then they will be recreated in their former glory. > This doesn't imply they shouldn't be mounted when > a desktop session starts. Yes, it does! Currently existing entries in /etc/fstab _prevent_ mounting these by non-root users. Quite on purpose and there is not a shred of a reason to complain about that. If I would want them to be mounted then I would have asked for this. I specifically DO NOT WANT them to be mounted and second-guessing my intentions is not doing any good. > Michal, I'm interested if you see any security issues with this? Well, I wrote explicitely "Not a show-stopper but a getting on nerves inconvenience". But there is actually a security angle to that. If you are bombarding users with a noise then they quickly stop paying attention to any messages of that sort and notifications about real problems are likely not to be noticed. This is _not_ an invented problem as anyone with a real life experience can attest. > This, btw, can be disabled in the g-v-m capplet (Hat > Menu->Applications->Preferences->Removable Storage) by disabling > automounting all together. In other words all or nothing? Not very appealing but if you do not have anything better to offer .... Is this under a control of individual accounts only or also overridable by a system administrator? If the later control is absent then this is basically worthless especially if it is defaulting to an unsafe behaviour. Just asking. On one hand we are seeing SELinux, with all configuration and access control headaches that entails, and on the other hand stuff like the above. A very strange schizofrenia.
>> Which are put in by fstab-sync from hal such that such entries aren't >> mounted at startup. > >More precisely I edited them out from an insane garbage dumped >into my /etc/fstab by fstab-sync. I cannot remove them entirely >because then they will be recreated in their former glory. If you have specific complaints please air them but this is just noise above. With the current release of HAL you can set policy to not write out specific devices or write them out with the fstab flags you would find sane. It is very fine grain. >> This doesn't imply they shouldn't be mounted when >> a desktop session starts. > >Yes, it does! Currently existing entries in /etc/fstab _prevent_ >mounting these by non-root users. Quite on purpose and there >is not a shred of a reason to complain about that. If I would >want them to be mounted then I would have asked for this. >I specifically DO NOT WANT them to be mounted and second-guessing >my intentions is not doing any good. David was refering to the noauto flag. Its only purpose in life is to make sure a drive is not mounted on boot. HAL will not second guess you as fstab-sync policy has been added for fine grain lockdown of removable devices. >> Michal, I'm interested if you see any security issues with this? > >Well, I wrote explicitely "Not a show-stopper but a getting on >nerves inconvenience". But there is actually a security angle >to that. If you are bombarding users with a noise then they >quickly stop paying attention to any messages of that sort and >notifications about real problems are likely not to be noticed. >This is _not_ an invented problem as anyone with a real life >experience can attest. I can say the same for your style of bug reports. As I said I am interested in your complaints but it makes it much easier to get through if the noise is kept down to a minimum and the actual substance of the complaints are aired. >> This, btw, can be disabled in the g-v-m capplet (Hat >> Menu->Applications->Preferences->Removable Storage) by disabling >> automounting all together. > >In other words all or nothing? Not very appealing but if you >do not have anything better to offer .... > >Is this under a control of individual accounts only or also >overridable by a system administrator? If the later control is >absent then this is basically worthless especially if it is >defaulting to an unsafe behaviour. Just asking. This is totaly controlable by the sysadmin. You can define how drives are mounted though the fstab-sync policy and you can edit the default schema's for gnome-volume-manager to set automounting to false. >On one hand we are seeing SELinux, with all configuration and >access control headaches that entails, and on the other hand >stuff like the above. A very strange schizofrenia. There is no one usecase so we need to be flexable. Anyway most of your complaints for HAL are already addressed in the current rawhide packages though I would wait until tomorrow to upgrade because David is fixing a bug that showed up with the new kernel today (older kernels work fine). As for gnome-volume-manager trying to mount root partitions I am going to file this upstream. As you said yourself it is not a critical bug and we are in a freeze right now. The best solution is to turn automounting off by default. If a patch comes soon I might be able to sneak it in. Moving upstream.
Upstream bug: http://bugzilla.gnome.org/show_bug.cgi?id=155532
I think that in all these explanations the real sense of my report got lost. Let me restate. The problem as I see it is as follows. Something (as I wrote I am not sure what that really is, maybe 'hal', maybe something else, but that is a detail) finds in /etc/fstab an entry with options which are not allowing that something to mount the file file system in question. How this entry got there is really at this moment immaterial. Now instead of noting to iself "ok, this is not mine; lets move on" this something spills, directly or indirectly, mount: only root can mount <whatever> The only reaction to that can be "Doh! Yes, we know that and we want it that way." Debugging messages are great in a development phase but we are pretty close to a release now. If you prefer this is about a quality of implementation. If you are trying to say that newer versions of whatever is involved here are not doing the above anymore the this is great and the problem is solved. Otherwise I think that there are still some loose ends. I had no opportunity yet to see that for myself.