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
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):
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:
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
(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:
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: 
Changing version to '9' as part of upcoming Fedora 9 GA.
More information and reason for this action is here:
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, and if I have other
Linux distros I don't want them mounted either.
 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
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:
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.