This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours

Bug 251062

Summary: auto-mounted for root file systems are left unmounted after log-out
Product: [Fedora] Fedora Reporter: Michal Jaegermann <michal>
Component: gnome-volume-managerAssignee: David Zeuthen <davidz>
Status: CLOSED WONTFIX QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: high Docs Contact:
Priority: low    
Version: 9CC: mclasen, peterm, security-response-team, tmraz, triage
Target Milestone: ---Keywords: Reopened, Security
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard: bzcl34nup
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2009-07-14 13:50:46 EDT Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:

Description Michal Jaegermann 2007-08-06 16:15:16 EDT
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
Comment 1 David Zeuthen 2007-08-06 17:23:07 EDT
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.
Comment 2 Michal Jaegermann 2007-08-06 17:42:26 EDT
> 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.
Comment 3 David Zeuthen 2007-08-06 18:51:18 EDT
(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.
Comment 4 Alan Cox 2007-08-06 20:37:49 EDT
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
Comment 5 David Zeuthen 2007-08-06 20:44:07 EDT
(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.
Comment 6 Michal Jaegermann 2007-08-06 21:57:58 EDT
> 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?
Comment 7 David Zeuthen 2007-08-06 22:22:54 EDT
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).
Comment 8 Michal Jaegermann 2007-08-06 22:41:35 EDT
> 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.

Comment 9 Michal Jaegermann 2007-08-15 15:31:34 EDT
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.
Comment 10 Michal Jaegermann 2007-10-05 14:16:50 EDT
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. 
Comment 11 Michal Jaegermann 2007-11-15 01:31:38 EST
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
Comment 13 Michal Jaegermann 2007-11-30 16:43:43 EST
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.
Comment 14 Bug Zapper 2008-04-04 09:33:21 EDT
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.
Comment 15 Michal Jaegermann 2008-04-04 12:55:28 EDT
I have seen that a number of times with current rawhide.
Comment 16 Lubomir Kundrak 2008-04-08 16:00:29 EDT
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!
Comment 17 Bug Zapper 2008-05-13 23:06:52 EDT
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
Comment 18 Clyde E. Kunkel 2008-05-30 14:45:38 EDT
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.
Comment 19 John Summerfield 2008-05-30 18:42:52 EDT
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.
Comment 20 Bug Zapper 2009-06-09 18:44:37 EDT
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
Comment 21 Bug Zapper 2009-07-14 13:50:46 EDT
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.