Description of problem:
After the last update, and with gnome-volume-manager working again (see
bug #176445) removable media (CD, USB floppy, USB memory stick) do not mount
at all and icons for USB devices do not even show in "Computer" window.
Regular floppy is plain unmountable for non-root accounts.
OTOH a nasty security bug #133584, much discussed and eventually resolved
at that time, rears its ugly head again under a different disguise and loging
even on non-root account quietly populates /media with such crap like
/media/disk, /media/disk-1, and so on. Some of these new mount points
are even owned by non-root although I cannot really comprehend criteria
by which one or another owner is picked up.
Add to that labeling requirements by current selinux and such unwanted
and highly undesirable automatic mounts are becoming even much bigger headache.
Version-Release number of selected component (if applicable):
With hal-0.5.5.1.cvs20060109-2 fixed disk partitions do not mount automatically
on login, luckily enough, but this seem to be true also for anything else, like
hotplug USB devices or data CDs, so it is hard to tell what really caused that
vfat devices are owned by the user who mounts them. ext devices take whatever
permissions are on the device itself from what I understand.
WRT comment #1, fixed disk partitions are still being automatically mounted on
my system, up-to-date with hal-0.5.5.1.cvs20060109-2 and rawhide. Is there
something else I need to do to prevent this?
Michal, please explain the attack vector in detail?
Btw, adressing comment #1, it sounds like a bug if we're not automounting
partitions from fixed disks. Comment #3 seems to confirm this.
Responding to comment #3 the answer is simply to disable automounting in the
"Removable Drives and Media" capplet available in System -> Preferences in the
Ahh, yes, that solves the problem of non-removable fixed disk partitions being
mounted. How can such mounting be a bug as the first part of comment #5
suggests? I would think only removable hard disk partitions (USB, 1394, PCMCIA,
etc) would be candidates if "Mount removable drives when hot-plugged" is checked
(btw, when only the "Mount and Browse removable media when inserted" are
checked, all non-removable hard drive partitions are still mounted. I run
selinux=0 on the grub kernel boot command line.
An attack vector is very simple. Assume for the moment that you are
on multiuser machine. Yes, Linux is used in that way too. A system
administrator obviously has some good reason not to mount some fixed
disk partitions or otherwise s/he would put these in /etc/fstab. What
these reasons are you do not have a clue as you cannot second-guess
reasons of a system owner. Now some user logs in on a desktop and,
surprise, all what was NOT supposed to be mounted now is just fine
accessible, with who knows what kind of information there, to whomever
happened to be logged in. Moreover some of these mount points are
even owned by that non-root account. I cannot find a rhyme-or-reason
for the later as my system in the current state does not mount via hal
anything at all.
All of the above was already patiently explained, and resolution reached, at
Please re-read if things are still not clear. That discussion points also
some other serious flaws in such random mounting.
A suggestion from comment #5 is patently ridiculous. We are not
talking here about _removable_ media but fixed ones. It is highly
likely that an owner really wants removable media to be mounted. In
any case - on my machine these "Mount" boxes in preferences are
checked in and this does not happen for removable media. It used to
in the past.
Re comment #7 note that the partitions don't get mounted with any particular
options (except for vfat) that e.g. changes whoever owns the files. Thus, the
system owner only needs to ensure that files he wants to keep private are
secured using traditional permission mechanisms. This includes practises such as
synchronizing uid's across systems and so forth. Yes, it's more work.
At this point I'd also like to remind you that only the console user is allowed
to mount these drives. Specifically, the console user may just boot into the
other OS'es used for the other disks and/or disassemble the system and pull out
the disks. He may even boot a live CD and access all data. Physical access to a
box is very hard to guard against.
I'd also like to remind you that if you don't like this you may just uninstall
gnome-mount and use your own hand-coded /etc/fstab entries. That will still work
for some time to come. Oh, you may also tweak the /etc/dbus-1/system.d/hal.conf
file but I'm not in a mood to walk you through this at this point.
Btw, if you didn't know, we're trying to make it easier for the console user to
use his system even it that means more post-installation work for experts like
you. John, shall we close this bug as WONTFIX or NOTABUG? John, we should
probably release note this as well as it's a change from earlier releases.
Btw, there are future plans for gnome-mount to do lock down via gconf mechanisms
but it's not implemented yet and it probably won't make FC5.
I must say I agree with Michal:
> Responding to comment #3 the answer is simply to disable automounting in the
"Removable Drives and Media" capplet available in System -> Preferences in the
How's a setting for REMOVABLE drives and media affecting NON-REMOVABLE drives
not a bug?
> Thus, the system owner only needs to ensure that files he wants to keep
private are secured using traditional permission mechanisms.
This doesn't do any good for FAT partitions, which have no permission
mechanisms at all, nor does it address the issue of ext3/SELinux file system
> Btw, there are future plans for gnome-mount to do lock down via gconf
mechanisms but it's not implemented yet and it probably won't make FC5.
Which means those who don't want it can't even turn the bloody (mis)feature
off! :-( Not to mention that it should be off by default. (What ever happened
to "secure by default"? And "safe by default" too, see the issues with SELinux
file system mangling.)
/etc/fstab really exists for a reason. Why not simply make it easier to add
partitions to fstab in firstboot (and ONLY in firstboot)? Firstboot could probe
for partitions the same way HAL or gnome-mount now does and then allow you to
check/uncheck the ones to be added to fstab. And if you leave them unchecked,
they should be left alone. HAL/udev/hotplug are the right tools for removable
media, but they do not make sense for disks which don't change.
Thinking a bit more about it (not that I'm changing my mind,
I still think the console user should be able to mount internal
disks in the default install), it might be useful for the Mount()
method in HAL to fail if the system administrator listed the
partition in /etc/fstab. Hence, if the user lists e.g.
/dev/hdb2 /no/path ext3 defaults 0 0
then attempts to mount /dev/hdb2 via e.g. gnome-mount or
dbus-send will fail.
This seems to me like a good compromise; it's something that is
easy for system administrators to understand plus it's easy to
express in the release notes.
I will go ahead and implement this - we should be able to get
this in FC5.
Re comment #8
> Re comment #7 note that the partitions don't get mounted with any particular
> options (except for vfat) that e.g. changes whoever owns the files.
Who owns files is only a very small part of the picture. If you happen to own
a mount point you can, for example, remove and add files. Also there is a good
chance that you will be able to **read** them. Various security bugs deal
with a possibility that in some circumstances you have an information leak
because you will be able to read, maybe, some piece of a shared memory and it
may contain something which you should not see. Here you do not have just
a possible leak but you are opening the whole floodgate to create a river
which can carry the big fleet and curiously enough this does not seem to faze
you at all. Really hard to comprehend.
still looks like applicable.
> I still think the console user should be able to mount internal disks in the
> default install
Here we go again. You have no idea what is on that disk. You have no
idea why it was not mounted in the first place. And you dare to presume
that you know better. Well, no, you don't.
> If you happen to own a mount point you can, for
> example, remove and add files.
The mounts created via gnome-mount are created by root; no
existing mount point is ever used for this.
I expect system administrators to read the release notes
when FC5 comes out and then they will know what to do in
the unlikely event they don't want console users to access
certain disks on the system.
> The mounts created via gnome-mount are created by root; no
> existing mount point is ever used for this.
With this exception that to my great surprise after login as 'michal'
I found one of newly created mounts owned by 'michal'. The other were
indeed owned by 'root' and all that junk in /media was newly created.
As I wrote, I cannot try to check what is going on as at this moment
all this stuff does not work for me at all for unknown reasons.
Besides this random mess is not that useful after all. For example
one of partitions should be mounted at 'usr' directory of another file
system to make some sense. Other things of that sort. Clearly this does
Hmm, this is all getting pretty unproductive. Michal, I have no idea what you
are talking about and can only guess that you have some snapshot of HAL that did
some things that have since been fixed but that other problems have prevented
the whole mount system from working in recent updates. First before we can even
descuss this we need to work through that problem. So first thing is first, how
did you update you machine. Is it fully up to date rawhide?
Second, andf this should come after we have you machine working - what are the
partitions you have which pop up. What file system do they use and how are they
being mounted. I would just want a list in a spreadsheet like format i.e.
mount type options permissions should_be_mounted
Let's try to make this discussion more concrete: What's the benefit of deciding
to mount file systems on non-removable disks at runtime rather than at install
time? Non-removable disks, by their nature, rarely change. So why not make this
an install-time decision? Because a well-known competing operating system
assigns drive letters to any disk it can find each time it is booted (which
creates tons of issues related to drive letters changing and breaking all paths
which relied on them - your automatically assigned drive numbers have exactly
the same problem)?
A while ago after some discussions, which clearly only partially were taking
place in bugzilla, some reasonable policy was derived which was summarized in
At that time indeed the talk was mostly in terms of an implementation mechanism
although it was quite obvious that concerns were about effects.
Recent changes patently violate that policy and open the same problems, security
and otherwise and plus some more, as before. Not mentioning this detail that
if you have more that one such "force mounted" partition then most likely
you are ending up with a nonsensical mess of "separate" file systems. I really
have no taste to go through the same discussion again about issues which were
That in this particular moment lots of things on a Gnome desktop are messed up
is not that important and this will likely improve soon. This only makes hard
to see what are effects, if any, of other modifications.
Then this is not a bug. The rest should be brought up on the HAL list if you
wish to continue it further.
Reopening because its clearly a problem area still.
We have a specific problem if we automatically create mounts for fixed storage
devices. The moment you plug such a box into a fibrechannel setup at a large
business there are going to be nasty suprises.
Software should fail safe. Thats rule #1, not 'the user should not have to
think', although that is probably rule #2
There are some other problems too. If the device is shared between systems (eg
fibrechannel) and you mount it when it is mounted elsewhere you've just trashed
the file system, even in some cases if the mount is "r/o" because of journal
replay. So I'd rather we fixed this promptly before it leaks into future RHEL
and we smoke some banks storage arrays, and indeed before we trash a system with FC
There is another reason not to mount everything too - the kernel may use
considerable resources on these unused mounts.
This is all a bit different to USB keys (where multiple mounts are kind of
tricky to achieve and physical presence is implied).
The owner of the computer should for himself decide wich partitions are visible
after reboot. Sind the last update I get all of them mounted in the media tree
even if they are already noted as user mountable in /etc/fstab by label and
LABEL=/1 / ext3 defaults 1 1
LABEL=/boot /boot ext3 defaults 1 2
LABEL=/home /home ext3 defaults 1 1
LABEL=/vmware /vmware ext3 noauto,user 1 2
LABEL=/iso /iso ext3 noauto,user 1 2
LABEL=/ix /iX ext3 noauto,user 1 2
LABEL=/free /unused ext3 noauto,user 1 2
LABEL=/ /mnt/centos4 ext2 noauto 1 1
LABEL=/12 /mnt/fc3 ext2 noauto 1 1
LABEL=/123 /mnt/suse93 ext2 noauto 1 1
The lables are:
The resulting table after reboot is
/dev/hda10 15507312 7567320 7139556 52% /
/dev/hda2 101105 64331 31553 68% /boot
/dev/shm 517964 0 517964 0% /dev/shm
/dev/hda11 69346584 57251464 8572472 87% /home
/dev/hda8 15757248 5057632 9899180 34% /media/disk-1
/dev/hda11 69346584 57251464 8572472 87% /media/disk-3
/dev/hda9 15757248 71912 14884900 1% /media/disk-2
/dev/hda7 16516052 77888 15599172 1% /media/disk
/dev/hda5 16516052 77888 15599172 1% /media/disk
There are even two partitons mounted on the same mountpoint '/media/disk'
After the latest reboot I noticed, that the result is not even reproducable.
/dev/hda10 15507312 7558572 7148304 52% /
/dev/hda2 101105 64331 31553 68% /boot
/dev/shm 517964 0 517964 0% /dev/shm
/dev/hda11 69346584 57191776 8632160 87% /home
/dev/hda11 15757248 8583804 6373008 58% /media/disk-1
/dev/hda7 15757248 8583804 6373008 58% /media/disk-1
This 'feature' really should be OFF per default.
hal-0.5.6-2 has a temporary fix which sets all fixed disks to be ignored.
Upstream is working on a more flexible solution.
By way of more info on the resource cost of trying to mount everything rather
than doing it when the admin asks:
Usage depends on file system for per fs cost. Worst cases are things like
reiserfs where a large reiserfs mount takes several megs of ram for its internal
data (and can take several minutes to mount). Ext3 takes a lot less but can take
a minute or so to play back the journal and costs you a thread each instance,
ext2 if clean is quick, if not must be fsck'd first and that can take ages. FAT
(if clean) is pretty fast and low cost. XFS I can't work out as its such complex
There is then a second cost which is the resources allocated to keeping the
block device open. If it is just another partition on an IDE disk its pretty
low, if its the only cause of a disk being active (especially SCSI) it tends to
cost half a MB or so, much more on some controllers.
Add ~30-60 seconds per physical disk (not fs) if the disk is spun down. For ATA
you can't easily avoid spin up while probing, for scsi you can access some stuff
and status info in this state so may be able to do smarter things.
The automounter (autofs4) is designed to let you avoid a lot of that cost by
deferring actual mounts of file systems but is rather Linux specific in form. It
also doesn't solve the shared access problems with scsi, fc, firewire etc, or
the security one but it may be useful for performance and startup speed by
deferring the actual costs. It could help with the security one as an fs
where /media/disk was root/root 0700 would block non root access regardless of
the permissions on the device itself.
Another useful key might be to look at the block device permissions as these are
partly controlled by pam. If the console user owns the device file then I can't
see a case where giving them the an autofs4 entry and mount/access ability is a
problem as they can scribble on the media directly.
These are all useful datapoints. Thanks Alan. With HAL doing the mounting
right now we can certantly put some huristics in and even do things like adding
entries to the automounter instead of actually mounting the device. Great thing
is every system that uses HAL can supply its own mounting application or script
so even though the automounter is linux specific we can add it even if upstream
Just to let know we are working on solving this problem upstream
We might not get the UI in time for FC5 but I definitely think the text-based
configuration will land in time for FC5.