Red Hat Bugzilla – Bug 133584
fstab-sync by default allows any uid to mount/umount non-default filesystems
Last modified: 2013-03-05 22:41:25 EST
Description of problem:
After recent updates and a reboot the following extreme garbage
showed up automagically in /etc/fstab:
/dev/sda9 /media/scsidisk ext3 \
noauto,user,exec,kudzu 0 0
and so on for **every** hard disk partition which happen
to be not mounted by a regular system startup. Who, on earth,
can automatically guess for what purposes these partitions
were set aside, what is there, and why every Dick-and-Harry
which happens to get a login on system should get automagically
mount priviledges on these file systems? Not mentioning 'exec'
rights on the top of it which makes that even worse! This is
a ***security hole*** which stinks to the high heaven.
On the top of it these entries are lacking a context, and awareness
of relatioships between these partitions, and so are totally devoid
of any sense. To add insult to injury this is causing a desktop
to produce a series of garbage icons which real function is only
to add a clutter.
If such behaviour may have some excuses for removable media
it is totally unacceptable for fixed file systems. In the past
there used to be 'updfstab' with /etc/updftstab.conf which allowed
at least some control over such things. Now it is gone and it
is even hard to guess where to try to revert the damage. Wherever
such thing is, if it exists at all, defaults are clearly backwards.
Version-Release number of selected component (if applicable):
No obvious way to kill it.
This is not a bug. It's about sane defaults so people don't need to
open a shell to access their partitions.
Since it appears that you are upset about the defaults you can simply
just remove the user and kudzu options and unprivileged users are not
able to mount those partitions. It won't help removing the line
entirely because then it will be readded on next boot (or next time
the haldaemon starts).
FYI there will be a /etc/fstab-sync.conf file before test3 such that
this behaviour can be customized. E.g. you will be able to specify
that fixed media shouldn't automatically be added to the fstab. You
will also be able to specify a number of other things.
It is likely that the defaults for this configuration file will
implement the policy you are claiming is a bug. On the other hand the
defaults may be that entries are only added for hotpluggable and
Btw, mounted fixed disks won't be shown on the GNOME desktop in
forthcoming release of gnome-vfs2.
Sorry this is a bug, its not just a bug its totally insane. Reopening
PS: removable media only doesn't work either as a heuristic. A lot of
situations lead you to have storage volumes that are not just USB keys
Fedora's traditional solution to this has been to tie it to the
"console user". Can't we just use the "owner" option instead of "user"?
> It's about sane defaults so people don't need to open a shell
> to access their partitions.
I am truly astonished that I have to explain such things here
but NONE of these file systems (partitions) is "their" until
a sysadmin will say so and will set an access boundaries. You
are quietly changing that behind sysadmin back. This detail
that on some systems a sysadmin may be their sole user is not
relevant here. Alan was very kind calling that "totally insane"
(so much for "sane defaults"). I was sorely tempted to use much
If you are on a quest to save a sysadmin from a shell (shrug!)
then write 'system-config-fstab', or whatever, and you can stick
into it all menus and eye-candy you desire; but in no circumstances
you can usurp vital policy decisions.
Responses in comments #1, #2 and #5 show a total lack of understanding
of the most elementary issues here. Hello? Wake up! Who brought
crack to Red Hat.
One way to solve this is to not put the user option on the /etc/fstab
entries and the UI could deal with lack of permissions through
existing authentication methods (e.g. consolehelper style) - this will
even give better security than before wrt. e.g. usb keys.
Once we switch to using the "owner" attribute, I don't understand the
practical threat here. If someone has physical access to a system
(what the owner attribute essentially means, you logged in via local
GDM or login), they should have permission to plug in USB devices by
default. Actually I haven't tested that GDM doesn't give console user
access to logins via XDMCP, but if it does I think that's a bug.
We should definitely document this, and make it easy to turn off.
Changes like this are what release notes are for.
You could just as well argue that our default of giving the console
user access to /dev/cdrom is a security hole.
Actually looking at it a bit closer, I had thought owner == console
privs, but it appears it only means that for the CDROM case because we
actually chown the cdrom device to the console user. So it seems we
do need a new mount option "console".
> Once we switch to using the "owner" attribute, I don't understand the
> practical threat here.
That would be funny if that would be not about serious matters.
Did you ever bother to check what "owner" means in this context
and an owner of what?
I strongly recommend re-reading of
and pondering a bit over this fragment about an expoxy glue.
And you are trying to sneek an instant access to every piece
of a disk? Amazing!
On comment 10: Michal, as Colin stated in comment 9 he is proposing a
new mount option called console. Obviously, this mount option would be
like user with the added requirement that the user needs to be at the
Obviously this is a better default as the console owner could just as
well physically nuke the box. Of course, if you now are referring to
public terminals I believe it would be a system administration bug to
leave partitions with valuable data anyway.
Remember, we're talking about the *defaults* and what they should be.
One of the goals is actually make people use their computer and
storage devices without 1) needing the root password and 2)
configuring from here to whoknows. Another one is security. It needs
to be balanced, and I'm certainly not proposing to make a insecure
system. In fact, I would rather err on the side of making the system
Do you have something constructive to add to this discussion?
In case it's not clear Michal, I also consider the "user" mount option
a serious security bug. It would for example allow a compromised
Apache daemon running as the "apache" user to umount a removable
But the threat scenarios from an authorized console user are far less
clear. If you have an actual situation where this would be a problem,
I'm interested to hear of it.
> We should definitely document this, and make it easy to turn off.
> Changes like this are what release notes are for.
Eh??? Make it easy to turn that ON and make obvious what kind of
access controls are in force. Defaulting to unsafe settings is
plain crazy. Also think for a fraction of a second about effects
of doing that to a raiserfs file system on an installation booted
with SELinux in an enforcing mode.
BTW - there is something like autofs. With executable maps
automounting of "other" file systems could be even useful as
otherwise this is just an annoying noise in all but the most
trivial situations. What is missing is a way for a non-root user
to unmount automounted volumes other then a timeout. Think about
it and make easy to use that and leave stupid /etc/fstab hacks
> Defaulting to unsafe settings is plain crazy.
I am stating that using console user authentication is "safe". If you
disagree, please describe why.
> Also think for a fraction of a second about effects
> of doing that to a raiserfs file system on an installation booted
> with SELinux in an enforcing mode.
What specific problem are you referring to? Since reiserfs doesn't
support xattrs, it will simply get a generic context like reiserfs_t.
It's tunable whether or not the user has access to it. And note that
all of the normal Linux permissions apply - SELinux is only in
*addition* to those.
> I am stating that using console user authentication is "safe".
You may be stating whatever you please but you cannot _know_ that
as you have no information about what may be on those file systems
and why they are present. That is the whole point. Random
guesses replacing a basic security is an insanity beyond
comprehension. It is not even worth a discussion. People,
what is wrong with you?
If you are lacking vestiges of imagination I may have on such
file system a backup of another machine (the real life situation
and far from unique). User id's between the two may, or may not,
be uniqe. Now you allow a random login to mount that at will
(and a GNOME desktop does that even without asking - which is
another story). Hello, anybody home? Examples of that sort
> Since reiserfs doesn't support xattrs ...
I only know that reiserfs indeed doesn't support xattrs and that
people with such file systems and installing FC3t2, where selinux
is by a default on, were complaining about troubles and errors.
It is not likely that this will not happen if you will mount
some random file system.
But I agree that in this context specifics of reiserfs may be
just a distraction. OTOH various unintended consequences when
you are springing surprises on a system owner by overriding
access policies constitute a clear and present danger. It completely
floors me that I have yet to explain such elementary things.
> If you are lacking vestiges of imagination I may have on such
> file system a backup of another machine (the real life situation
> and far from unique). User id's between the two may, or may not,
> be uniqe.
Sure. Now that we're talking about a more practical situation, let me
ask you - do you have any other users that log in with console privileges?
But definitely, if you do such a thing, you should certainly be aware
of the ability for console users to mount filesystems. I would put
all your partitions in /etc/fstab manually with
That should prevent any inadvertent access by users. If you didn't do
something like this you'd have to be very careful when manually
mounting the filesystem, since if you forgot to pass these options and
mounted it in /mnt, then *any* user would have access.
> I only know that reiserfs indeed doesn't support xattrs and that
> people with such file systems and installing FC3t2, where selinux
> is by a default on, were complaining about troubles and errors.
That's simply a user error for trying to install the entire system
onto reiserfs with SELinux enabled. Totally different and unrelated.
> It is not likely that this will not happen if you will mount
> some random file system.
I'm quite sure it will not be a problem. If you have actual evidence
to the contrary, I'm interested.
> OTOH various unintended consequences when
> you are springing surprises on a system owner by overriding
> access policies constitute a clear and present danger. It
> floors me that I have yet to explain such elementary things.
Actually I thought about the issue quite carefully. Your example of a
backup with other uids did occur to me. But I doubt there are many
systems out there where the system administrator:
1) Follows such a practice of mirroring filesystems, without using
something like tar+gpg to encrypt backups
2) Has desynchronized uids across systems
3) Doesn't have the lines in /etc/fstab already with restrictive
4) Has untrusted users who log in via the console, as opposed to ssh
If you are one of them - well, I sympathize, but you're in the
minority. The improvement in functionality for the vast majority of
users is worth the trouble for the few.
Incidentally, the overall plan is to continue to carefully make the
console user more powerful. If you don't want this, I suggest simply
removing pam_console from /etc/pam.d/*. Then Fedora instantly reverts
back to "traditional" Unix, where you can't use USB or Firewire, can't
play CDs, can't configure your network, etc.
You have a serious security bug and that is it. No amount of
kvetching on your part is going to change that. I am through
trying to explain things which should be obvious to beginners.
You know, I tried to work with you carefully and patiently to find out
whether there would still be a security problem in your situation if
we keyed access off console privileges. If you're not going to give
me a "yes" or "no" answer, then I just have to assume the problem is
We will still keep this bug open until the console mount option is
implemented and fstab-sync is changed to use it. Thanks for pointing
out the original security issue.
Sigh! It is not "mine situation". You got that totally wrong
and that is a big part of the problem. If that would be only this
that it would be not raising dangerously my blood pressure.
Console priviledges really mean that whomever happens to own
a console (assuming "owner" here and not "user"), i.e. sits in a front
of keyboard, can mount things like CDs and floppies. What you
are saying that this is also fine, and apparently even with less
restriction than that, for any random file system which happens
to be present on disks and was not mounted when a system was
coming up. In other words, you _think_ that you know better what
policies should apply to some installations about which you cannot
have the slightest clue. This is truly insane. This detail if
console priviledges are involved or not is irrelevant.
I agree that in some situations and with some file systems granting
such access may make sense. So fine, make it easy to turn such
access on and provide reasonable defaults for its control __when__
such thing is granted. The problem is that right now this is
exactly backwards but you are trying to discuss fine points.
I would be fine with adding the "console" option for "removable" media
only. But the problem is that "removable" isn't easily defined.
> In other words, you _think_ that you know better what
> policies should apply to some installations about which you cannot
> have the slightest clue. This is truly insane. This detail if
> console priviledges are involved or not is irrelevant.
Actually it *is* relevant. Because if there aren't any, or are very
few cases where this would be an actual problem, then we're fine.
Look - by default, the console user can already reboot the machine,
write to the CDROM device, etc. Mounting removable media is an
obvious logical extension. If you don't like any of this, don't use
> Actually it *is* relevant. Because if there aren't any,
You got an example of a situation with a big problem. So that
assumption is trivially false.
> or are very few cases where this would be an actual problem,
If there are "few" then you have a big problem and you have
no way of knowing how big this "few" really is.
> then we're fine.
Are you sure that you work on the right OS? Maybe you would
feel better somewhere else?
Tell you what? If Alan Cox will say that you are right then
I will keep my mouth shut. Go and ask.
> You got an example of a situation with a big problem.
What big problem? You only provided yourself as an example, but
didn't say whether or not you have hostile console users.
> If there are "few" then you have a big problem and you have
> no way of knowing how big this "few" really is
True, but I suspect it's very small (maybe slightly larger than the
number of people who have problems with the console user having access
to /dev/cdrom). Your implicit confirmation that you don't have any
hostile console users only bolsters my conclusion.
> Are you sure that you work on the right OS? Maybe you would
> feel better somewhere else?
I am quite happy to be working on an OS that cuts a sensible line
between security and usability.
> Tell you what? If Alan Cox will say that you are right then
> I will keep my mouth shut. Go and ask.
Heh. If Alan can make some arguments against the default console user
access, he is free to comment in this bug. I'm especially interested
in real-world situations where it's a problem. So far I've only heard
a lot of handwaving.
I've provided a whole pile of reasons internally. The proposed fstab
change is still completely and totally insane. The fact you as you
admit "dont understand" half the issues doesn't make them go away.
All 'console user' proves is you are the console. It doesn't prove you
have any administrative rights to the system, and it doesn't tell you
anything about where storage device are.
The existing code works because we assume physical access for poweroff
is ok (argument that if you physically access the box you can power it
off anyway, with an axe if need be). We know the floppy must be within
a few inches of the console likewise.
"Removable" devices could be anywhere and we have no way of tying them
to an owner. So while we can possibly argue that we know a USB
connector is "probably" near the console user we have no idea where
and what random pieces of removable storage media are.
To the kernel "removable media" means hot-pluggable. So your
enterprise database will be appearing as "user" in the fstab. I'd hope
that strikes you as a bad idea.
> The fact you as you admit "dont understand" half the issues doesn't
> make them go away.
I didn't say that I didn't understand the issues. I said that I
didn't understand the practical threat here, and that's *still* true.
No one has yet elaborated on an actual real-world situation where
this is a problem.
> All 'console user' proves is you are the console. It doesn't prove
> you have any administrative rights to the system,
No, but it does prove that you should be able to use removable media.
> "Removable" devices could be anywhere and we have no way of
> tying them to an owner. So while we can possibly argue that we
> know a USB connector is "probably" near the console user we have
> no idea where and what random pieces of removable storage media
The exact same argument could be applied to wacky CD-ROM devices that
could be on some huge long cable far away from the user. Maybe
someone's created a transatlantic IDE cable, so you can play a CD for
me from London.
But until I hear from someone who actually creates a USB connector
that is far away from the computer, *and* has untrusted users with
console logins *and* their filesystem permissions would permit access
by this console user, you're just handwaving.
> To the kernel "removable media" means hot-pluggable. So your
> enterprise database will be appearing as "user" in the fstab. I'd
> hope that strikes you as a bad idea.
First of all, it's not the "user" option. We are discussing the
"console" option which is in development. And again, you need
untrusted console users, and you need bad filesystem permissions (I'd
argue an "enterprise database" that doesn't have that is already
seriously flawed, and this is just exposing that flaw). You are also
assuming that the "enterprise database" isn't already in /etc/fstab,
which seems unlikely to begin with. And as we discussed internally,
we could have HAL ignore SAN devices.
Actually if you see the internal discussion you'll see that we cannot
even tell SAN devices and most of the other arguments you present as
"over" are not.
Ok the proposed solution appears to be something like this
Volumes we will add for mounting by the console user as a default (and
PC legacy floppy disks (as granted already by pam_console)
USB devices except where they hold an existing mount for the system,
(eg if /home is on USB we won't give access to it!)
The access in question is "console" not "any user", thus you must be
physically at the console to do this. At that point you can reasonably
remove any USB device, floppy or IDE CD-ROM and take it to another
Do you see any holes in that Michal (remembering also that for
'secure' installations where users are forbidden access to media we'd
be documenting how system administrators turn it off as we do now with
Some final discussion continuing
Another proposal is this one:
fstab-sync will add entries for all mountable partitions and drives
connected to the system. Only if the entry stems from USB, Firewire,
SATA, IDE or x86 legacy floppy and beginning of the volume label
doesn't match a FHS2.3 top-level mount point the 'console' option will
Alan, Marcel: thoughts?
In comment #27 Alan asks "Do you see any holes in that Michal".
It seems to me that this is more or less equivalent to the situation
we have right now although, again, fragments of
give some food for thought. Although competent sysadmins should
be able to handle various situations unfortunately not all of them
are so competent. On a longer run tools which would allow them
easier to handle access configuration to various file systems
would be nice.
I do not have a big quarrel with arguments raised here and there,
like in comment #16, that what we had up to now is somewhat messy
in places. But drawing from that a conclusion that therefore it
is OK to make a really big mess is something beyond my comprehension.
A proposal from comment #28 seems to me way too dangerous.
" ... and beginning of the volume label doesn't match". So all
of sudden a behaviour depends on a "correct" labelling over which
you may not have any control and you do not even know if filesystem
in question allow any labels. Sounds to me like a mine-field where
things mount or not apparently at random (until you observed a key
which is not so readily visible). An absolute security nightmare.
As for presumably "insecure" permissions on file systems which
are not "magically self-mounted" up to now then they are fairly
secure, thank you very much. Only root can mount them so they
are rather hard to access by those unauthorized. If root will
get compromised then indeed you have problems. No surprises here.
After all this long discussion, when it started to look that
something begins to click, after updates to hal-0.2.98.cvs20040929-3
and gnome-vfs-1.0.5-21 I am indeed not greeted on a desktop with
an icon for every possible file system.
BUT ... in /etc/fstab I am "blessed" now with
/dev/sda9 /media/scsidisk7 ext3 \
noauto,user,exec,managed 0 0
and so on, and so on, and a simple act of login to a graphic
desktop, with no further action on my part, caused 'mount' to
show the following definitely unwanted junk:
/dev/sda1 on /media/scsidisk13 type ext2 (rw,nosuid,nodev,user=michal)
/dev/sda2 on /media/scsidisk12 type ext3 (rw,nosuid,nodev,user=michal)
/dev/sda3 on /media/scsidisk11 type ext3 (rw,nosuid,nodev,user=michal)
/dev/sda6 on /media/scsidisk10 type ext3 (rw,nosuid,nodev,user=michal)
/dev/sda7 on /media/scsidisk9 type ext3 (rw,nosuid,nodev,user=michal)
/dev/sda8 on /media/scsidisk8 type ext2 (rw,nosuid,nodev,user=michal)
/dev/sda9 on /media/scsidisk7 type ext3 (rw,nosuid,nodev,user=michal)
A huuuge improvement (NOT!). Well, some; at least 'nosuid' and
'nodev'. Was all this previous exchange a joke? Who needs their
heads examined pronto?
The work discussed isn't yet fully implemented. The patch for
'console' instead of 'user' have been submitted for util-linux for is
in yet; I've actually made it a blocker bug (as you should be able to
see from this bug); see bug 133941 for details.
It is being worked on.
Sorry! My mistake. I jumped a gun but sometimes it is hard to know
how long to wait.
Alrighty, I've uploaded a new hal package, hal-0.4.0-2, into Rawhide
as well as an updated util-linux package with a mount(1) that supports
the 'pamconsole' option. I've also patched gnome-vfs2 and uploaded
that into Rawhide such that it will show entries in /etc/fstab with
the pamconsole option (upstream gnome-vfs2 only shows entries with the
The new hal package features a man page for fstab-sync with
instructions on how to customize how and if entries are added. There's
also information on how to totally disable fstab-sync messing with the
/etc/fstab file. Also, fstab-sync now puts a comment in the /etc/fstab
file pointing the reading to the man page.
The defaults are now
fstab-sync will add entries for all mountable partitions and drives
connected to the system only if the entry stems from USB, Firewire,
SATA, IDE or x86 legacy floppy. The 'pamconsole' option will
and these are very easy to change. Notably, I've dropped the
requirement on not adding entries if the label starts with a FHS2.3
mount point - I don't think that makes any sense really, e.g. users
should be able to access the a harddisk from, say, an old server, in
an USB2 enclosure. See this screenshot for an example
The issue Alan raised here
> (eg if /home is on USB we won't give access to it!)
is in my view kind of moot as a well configured system will already
have an entry in the /etc/fstab with LABEL=/boot and fstab-sync won't
add an entry in that case. Either way, the defaults are easy to
change, so let's see if I should change that back; Alan, please comment.
FYI the default naming policy for mount points have also changed (but
is totally configurable), I'll send a message to fedora-devel today or
tomorrow about this. You might want to check out the mail I've sent to
the upstream hal mailing list
Marcel: thanks for filing this bug, I'm happy we've now got what I
consider a much better solution - I hope you think so to. I'm moving
this bug to MODIFIED and awaiting comments before I'm going to close
it as RAWHIDE.
Opps, Michal, much sorry for calling you Marcel. My bad.
My experiments with the current hal-0.4.0-3 seem to indicate
that fstab-sync aquired now so much desired sanity. Thanks!
There seem to be a problem what what is called above "legacy
floppy" and a policy spelled out in a comment #33 does not seem
to be applied in that case. It is possible that instead I do
not understand something here or maybe some configuration files
are messed up a bit. Still sounds like a bug different from
this one anyway. Right?
> My experiments with the current hal-0.4.0-3 seem to indicate
> that fstab-sync aquired now so much desired sanity. Thanks!
Thanks for reporting the bug and sorry it took so long to fix. I'm now
closing this bug as RAWHIDE.
> There seem to be a problem what what is called above "legacy
> floppy" and a policy spelled out in a comment #33 does not seem
> to be applied in that case. It is possible that instead I do
> not understand something here or maybe some configuration files
> are messed up a bit. Still sounds like a bug different from
> this one anyway. Right?
Yeah, this was bug 133777 which I've just closed.