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): hal-0.5.5.1.cvs20060105-2
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 effect.
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 GNOME desktop
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 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=133584 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 GNOME desktop 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 compatibility. > 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. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=133584#c24 unfortunately 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 not happen.
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 Thanks
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 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=133584#c33 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 apparently closed. 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 dedicated mountpoints: 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: /dev/hda2 /boot /dev/hda5 /free /dev/hda7 / /dev/hda8 /123 /dev/hda9 /dev/hda10 /1 /dev/hda11 /home /dev/hdb1 /12 /dev/hdb2 /ix /dev/hdb3 /iso /dev/hdb4 /vmware 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. I got /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 code. 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 structure of /media/disk/hda/.... 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 doesn't.
Just to let know we are working on solving this problem upstream http://lists.freedesktop.org/archives/hal/2006-January/004377.html We might not get the UI in time for FC5 but I definitely think the text-based configuration will land in time for FC5.