Description of problem: This looks like a resurrected bug 133584 although a mechanism now seem to be slightly different. See the referenced bug for an explanation why this is a very bad idea which may destroy data in some situations. IIRC this bug resurfaced on other occassions at least once more. It would be nice if we would not have to return to it again. Recent updates of 'hal' and 'gnome-mount' appear AGAIN to cause attempts to mount any _disk_ partition regardless if it was listed in /etc/fstab or not. They later show up in 'mount' output with (rw,nosuid,nodev,uhelper=hal) options. Outwardly this happens only in a 'root' desktop session but on an exit from such session some of these file systems get unmounted and some other do not, apparently in a random fashion. So if after that a sesssion for a non-root user is started then a random number of various "surprise" disk partitions (different numbers and different file systems at various times) show up on such desktop. To makes things more "interesting" while starting a session for root I can see that 'gnome-panel' starts, _some_ of these bogus mounts happen, a nautilus process apparently is there but no background or icons are ever shown. After a few login/logout tries the situation can be back to "normal". Version-Release number of selected component (if applicable): hal-0.5.10-0.git20070731.fc8 gnome-mount-0.7-0.git20070725.1.fc8 How reproducible: always
Why are you logging is as root? That's discouraged for a number of reasons that you should already know about. Just think about how much code is running as uid 0. If you log in as an unprivileged user this of course won't happen. However, the drives will still show up (unmounted) and unprivileged users can access them provided they input the root password. Just avoid logging in as root.
> Why are you logging is as root? That's discouraged for a number > of reasons Well, I don't. That is why it took me few day to notice that things got broken. OTOH until you will block gnome-sessions for root then you have a bug.
(In reply to comment #2) > > Why are you logging is as root? That's discouraged for a number > > of reasons > > Well, I don't. Obviously you did something to run the entire desktop session as root otherwise this wouldn't happen. > That is why it took me few day to notice that things > got broken. OTOH until you will block gnome-sessions for root > then you have a bug. If you avoid logging in as root this will never happen. Indeed, even if you _try_ to log in as root (both via startx(1) and gdm) you will get a prompt explaining you shouldn't do that.
Ok with my security related hat on I can see that mounting some extra partitions only root accessible if you login as root makes sense (except for remote disks like Fibre channel where you toast stuff) I don't understand why its been closed when the report indicates random partitions get left mounted or not and nautilus gets confused however. Seems to be closed in error
(In reply to comment #4) > I don't understand why its been closed when the report indicates random > partitions get left mounted or not and nautilus gets confused however. Seems to > be closed in error Maybe because no-one reassigned the bug to the proper component and changed the summary? Now fixed.
> If you avoid logging in as root this will never happen. Indeed. Does that mean that you plan to put various "landmines" breaking things in a random way for those who have a temerity to login into a gnome-session as root? As long as there is no outright policy to ban such logins then it is hard to consider such traps to be anything else but serious bugs. OTOH if I should avoid root logging then I do not understand why to be so "user-friendly" for root and mount random file systems on "/media/<some_string>" mount points which is most likely not what is desired anyway? What this is supposed to buy? When I looked what was mounted and unmounted (not everything in _both_ cases) I could not find any rhyme-or-reason for choices. If you would default to a policy "no filesystem of any kind is ever automounted for root" I would only applaud, as this would be definitely more secure in more ways than one; root can mount anything which is mountable, when a need will arise, regardless. It seems to me that this would trivial to implement (but it would deserve a prominent entry in RELEASE-NOTES). Also IIRC very old discussions automounting whatever was in sight carried a possibility of filesystem destruction at least in some SAN configurations. I cannot test that but is this not a concern anymore?
FYI, we've avoiding automounting anything for root in the past (if you have access to RHEL bugzilla just try and see how many people complains about it) because of some of the security reasons you mentioned. I'm fine with disabling automounting for root completely, in fact I'm unsure how that happened. I'll look into it. Keep in mind, in many ways, it's just papering over the problem. It's _fundamentally_ wrong to start GNOME, KDE or similar when running as uid 0; just the sheer amount of code alone should discourage you. If that's not enough, just consider that a good portion of that code deals with untrusted input (think web browser, image loaders, email applications, instant messaging etc.). That's why you get a dialog telling you it's the wrong thing. So I'd rather we disabled the ability to start such desktop environments as root instead. But then another set of people start complaining. > Also IIRC very old discussions automounting whatever was > in sight carried a possibility of filesystem destruction > at least in some SAN configurations. I cannot test that but > is this not a concern anymore? I think you refer to issues around early Rawhide (just before FC3) where members of RAID / LVM sets were incorrectly marked as being a block device with a file system (this sniffing is done in udev's libvolume_id).
> It's _fundamentally_ wrong to start GNOME, KDE or similar when > running as uid 0 It appears that your idea of "testing" is "if you will not do things from some list (which I keep in my head), you will not feed some random input to programs, and not do other things which I deem stupid, then the software is perfect". AFAIK this does not work that way in the real world. >> Also IIRC very old discussions automounting whatever was >> in sight carried a possibility of filesystem destruction >> at least in some SAN configurations. > I think you refer to issues around early Rawhide (just before FC3) > where members of RAID / LVM sets were incorrectly marked ... I think that there were concerns about a network storage, which could be possibly mounted from various mount points, of some SAN kind and not anything local (RAID / LVM or not). But I do not remember that precisely and could not find anything written down.
The main reason why this bug was filed originally against hal instead of some other component is that after logging into a root session I see in logs a series of entries like: hald: mounted /dev/sdaX on behalf of uid 0 and later on logout hald: unmounted /dev/sdaX from '/media/<something>' on behalf of uid 0 After an update to hal-0.5.10-0.git20070731.fc8.2 a "deficit" of unmounts went down but it is still there. This was observed on only one try so far. OTOH from commment #7: "I'm fine with disabling automounting for root completely, in fact I'm unsure how that happened. I'll look into it." So if automounting for root should not happen, which I think is only sane, then making hal to ingore mount requests "on behalf of uid 0", at least those "not explicit", would seem like the simplest way to ensure that something will not recreate the issue once again.
With Fedora 8 Test 3 (7.92) on us this bug is as present as it was on the beginning of August. I thought that everybody agreed that "automatic" mounts of file systems on a behalf of root is not something which should happen. There is one small difference. While in August "leftover mounts" after a logout from a root session were practically guaranteed now one needs to work quite a bit harder to get the same effect. This detail that trivially changeable default currently prevents root from loging into a graphics desktop does not really make the situation much less buggy.
This severe bug found its way into F8 release. On the first try on a test system after a logout from a root session I was left with NINE mounted under /media/ spurious disk file systems. An automatic mount of none of these was desired in the first place but it is far from clear how to prevent that from happening. Note that in /usr/share/gdm/defaults.conf there is "AllowRoot=true" so even that feeble barrier is gone. Current versions are: hal-0.5.10-1.fc8 gnome-mount-0.7-1.fc8
That bug not only was not fixed but currently this disease, and more, spread to non-root accounts in F8 and the current rawhide. For a description of nasty security consequnces see bug 401811.
Based on the date this bug was created, it appears to have been reported during the development of Fedora 8. In order to refocus our efforts as a project we are changing the version of this bug to '8'. If this bug still exists in rawhide, please change the version back to rawhide. (If you're unable to change the bug's version, add a comment to the bug and someone will change it for you.) Thanks for your help and we apologize for the interruption. The process we're following is outlined here: http://fedoraproject.org/wiki/BugZappers/F9CleanUp We will be following the process here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this doesn't happen again.
I have seen that a number of times with current rawhide.
Final Freeze is in effect now. Security fixes almost certainly warrant a freeze break, so in case you build a fix for this, mail release engineering as described here: [2] [1] https://www.redhat.com/archives/fedora-devel-announce/2008-April/msg00007.html [2] http://fedoraproject.org/wiki/ReleaseEngineering/FinalFreezePolicy Thanks!
Changing version to '9' as part of upcoming Fedora 9 GA. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
OK, how do we get around this for now? I have had to login as root once to fix a problem with the LV /home was on (now it is on a standard ext3 partition). Now when I logon as a normal user, I get every partition mounted on my rawhide test system. Is there something I can change until the fix requested in this bz is made. Thanks.
I disagree with Alan about mounting extra filesystems if root logs in, and I disagree vehemently with those who say, "don't login as root." This is not the time or place for preaching. It's my decision whether I login as root, and the extent to which that represents a security hazard depends on my context and circumstances which I know, but you don't. It's the software suppliers' responsibility to keep me safe without getting in the way excessively. I was horrified to find my NTFS partitions mounted rw[1], and if I have other Linux distros I don't want them mounted either. [1] I am not satisfied that Linux rw access to NTFS is safe. I certainly don't want Linux circumventing Windows security just because it can. Even if Windows' filesystems are safe, what about Solaris, OS/2, *BSD*, OS X filesystems? I don't like anything being mounted just because it can, even the CD-RW I've just inserted to rewrite.
This message is a reminder that Fedora 9 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 9. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '9'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 9's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 9 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Fedora 9 changed to end-of-life (EOL) status on 2009-07-10. Fedora 9 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.