Description of problem: With DeviceKit around various volumes from non-removable disks are getting automatically mounted, while nobody asked or allowed for it, on a desktop in a session for a non-root user and with the following options: (rw,nosuid,nodev,uhelper=devkit) So everybody with desktop session may scribble at will over, say, some backup storage and similar partitions. Desktop icons get such "informative" titles like "260 MB Filesystem". It appears that LVM volumes which show up in /dev/mapper/ were singled out for such misguided treatment only that in mount ouput they show up as /dev/dm-* devices. Curiously enough I have here nine such devices but six are automounted and the other three, which do not seem to be much different, are not. Version-Release number of selected component (if applicable): DeviceKit-disks-003-5.fc11 How reproducible: all the time Expected results: Non-removable volumes are NOT getting automouted unless some special arrangements, overriding defalts in specific cases, are explicitely made.
A couple of things - Your beef is with Nautilus; DeviceKit-disks doesn't automount anything, it's just a mechanism the same way the mount(1) is a mechanism. (or in case you are not using Nautilus, complain to whatever program is mounting your devices.) - FWIW, Nautilus doesn't treat non-removable different from removable when it comes to mounting file systems. Ergo, if there's a mountable filesystem on a device, it is mounted. If you don't like automounting, turn it off in Nautilus (/apps/nautilus/preferences/media_automount). Note that authorization is needed to mount a device. The authorization is different depending on whether the device is considered system-internal or not (system-internal is roughly equivalent to "removable and/or hotpluggable"). The user by default has authorization to mount non-system- internal, for system-internal the root password is needed (e.g. the user has no such authorization by default). Specifically the wish "Non-removable volumes are NOT getting automouted unless some special arrangements, overriding defalts in specific cases, are explicitely made." is not a wish Nautilus is going to honor I think. - The way we determine whether a file system is mountable is via udev; if you think udev is getting this wrong, file a bug with udev and include the appropriate data (output of something like 'udevadm info --query all --name /dev/sdb1') Closing the bug as CANTFIX since DeviceKit-disks is just a mechanism that doesn't enforce any policy (such as mounting) at all.
> Your beef is with Nautilus; DeviceKit-disks doesn't automount anything, If you know that then nothing stops you from reassigning component. It is hard to find way in this messy maze. I only know that after recent updates to DeviceKit-disks things started seriously misbehave. Morevoer in mount options there is "uhelper=devkit". My best guess is that the last is a short for "DeviceKit" and /sbin/umount.devkit happens to be owned by DeviceKit-disks-003-6.fc11.x86_64. > FWIW, Nautilus doesn't treat non-removable different from removable when it > comes to mounting file systems. Ergo, if there's a mountable filesystem > on a device, it is mounted. As noted in the report this is clearly NOT an observed behaviour. Some non-removable file systems are getting mounted and others are not without an apparent rhyme or reason. Besides there is a substantial difference between file systems on non-removable and removable devices. If they are non-removable and I want them mounted by default then they are in /etc/fstab; otherwise nothing should be doing second-guessing here for elementary security reasons. As a matter of fact none of these, unless explicitly allowed, should be listed when browsing "Computer". > If you don't like automounting, turn it off in Nautilus (/apps/nautilus/preferences/media_automount). Accordingly to what you said above this will turn off automounting for removable media as well. A quick experiment shows that this is indeed the case. Due to this gross misdesign this is not a good option. Moreover removables mounted while 'media_automount' is off remain mounted after a logout thus creating even a bigger mess. > Note that authorization is needed to mount a device. In that case there is something wrong with defaults. Some fixed storage file systems are get automounted while others are not. Contrary to what you are saying there is different between fixed and removable storage. They stay mounted even after a logout from a desktop seesion regardless of a status of /apps/nautilus/preferences/media_automount. With some other file systems displayed in a "Computer" browse window an attempt to mount will indeed bring a root password question (once per session - it appears - which, in my opinion, is too permissive) but this is not consistent and this is a problem. Once again - if you think that this is a wrong component then pick a better one.
Created attachment 335284 [details] an output from "udevadm info --query all --name=/dev/dm-1" > - The way we determine whether a file system is mountable is via udev; if > you think udev is getting this wrong, file a bug with udev and include > the appropriate data (output of something like 'udevadm info --query all > --name /dev/sdb1') A file system on that device gets automounted
Created attachment 335285 [details] an output from "udevadm info --query all --name=/dev/dm-2" ... and a file system on this device is NOT automounted. Can you explain that mysterious difference which is causing that?
Michal, what exactly are you complaining about in this bug? That some file system gets automounted and some doesn't?
> Michal, what exactly are you complaining about in this bug? Like the subject says. Some, apparently _random_, file systems from a fixed storage get now automounted on a start of a desktop session while other, without any reason which I can notice and even seemingly very similar, do ask for an authorization to mount; like you say that they should. This is a really recent phenomenon. I also tried to see what will happen if try to mount again those particular "automouting" file systems after unmouting and without mounting anything else. They get mounted again with no questions asked. I tested that with a different account to see if this will make any difference. The same file systems got automounted. Moreover after a logout from a desktop session they stay mounted too. That seems to be consistent with what happens with a file system automounted, say, from a removable USB stick (although I seem to recall that on other occassions ending a desktop session did automatically unmount that fs but I may be getting confused after many tries). Searches through /var/lib/PolicyKit, /var/lib/PolicyKit-public and /var/lib/DeviceKit-disks did not leave me any wiser. The only common feature I can notice is that all such automount points are using /dev/dm-? but as an attached examples point out this is not a sufficient; /dev/dm-2, and /dev/dm-3 too in my particular case, are left alone. If you would have any ideas what I am looking for then I would appreciate it. BTW - an automatic unmounting upon a termination of a desktop session filesystems mounted by this session seems like a really reasonable expectation. I have no idea what could/should be responsible for that.
OK, so lets go debugging. Please attach the output of 1. 'devkit-disks --dump' before logging in 2. 'devkit-disks --monitor-detail' while logging in 3. 'devkit-disks --dump' after logging in 4. 'polkit-auth --explicit-detail' and also please record if you did something like entering a password while capturing this information. > BTW - an automatic unmounting upon a termination of a desktop session > filesystems mounted by this session seems like a really reasonable expectation. > I have no idea what could/should be responsible for that. Yes, that is indeed planned http://bugzilla.gnome.org/show_bug.cgi?id=574566 http://bugs.freedesktop.org/show_bug.cgi?id=20691
Oh, and also please attach the contents of your /etc/fstab file. Thanks.
Created attachment 335403 [details] /etc/fstab used on a test installation Looking closer at /etc/fstab provides an explanation to at least some mystery. Those file systems which _may_ show up as /dev/dm-* but also are listed in /etc/fstab with "noauto" option are NOT getting automounted. They do not show also in a "Computer" browser window and if I am trying to use 'gnome-mount' with these I get in a response "... is not a volume or a drive". So this looks at least as an apparent workaround. :-)
Created attachment 335407 [details] 'devkit-disks --dump' before logging in All this information, and subsequent attachment too, was produced while logged from another machine via ssh with an authorized key (so no passwords were typed).
Created attachment 335411 [details] 'devkit-disks --monitor-detail' while logging in
Created attachment 335413 [details] 'devkit-disks --dump' after logging in
> 'polkit-auth --explicit-detail' That command, as well as something like 'polkit-auth --user michal --explicit-detail', returns immediately with no output.
Hi, Thanks for the output, apparently we are setting system-internal to an incorrect value for device-mapper devices; should be easy to fix. Stay tuned for a fix. (In reply to comment #13) > > 'polkit-auth --explicit-detail' > > That command, as well as something like > 'polkit-auth --user michal --explicit-detail', returns immediately with no > output. That's expected if you don't have any authorizations. (In reply to comment #9) > Looking closer at /etc/fstab provides an explanation to at least some mystery. > Those file systems which _may_ show up as /dev/dm-* but also are listed in > /etc/fstab with "noauto" option are NOT getting automounted. Right. DeviceKit-disks respects the system-wide /etc/fstab file; e.g. if an unprivileged user invokes Mount() and the device (or a symlink to it) is referenced in /etc/fstab then we just invoke mount(1) as the calling user. This allows administrators to customize mount options / policy on a per-device (using /dev/disk/by-id/* or /dev/disk/by-uuid/* symlinks) or per-connection/port (using /dev/disk/by-path/ symlinks) basis. > They do not show also in a "Computer" browser window and if I am trying to use > 'gnome-mount' with these I get in a response "... is not a volume or a drive". > So this looks at least as an apparent workaround. :-) Note that gnome-mount is deprecated and not used anymore; one replacement is gvfs-mount.
(In reply to comment #14) > Hi, > > Thanks for the output, apparently we are setting system-internal to an > incorrect value for device-mapper devices; should be easy to fix. Stay tuned > for a fix. Should be fixed here http://koji.fedoraproject.org/koji/taskinfo?taskID=1250267 otherwise please reopen. Thanks. David
It does "worksforme" after updates eventually showed up. Thanks!
I am not sure if this a separate bug or something the current fix didn't get. When adding elements back into raid arrays I was getting popups in the desktop where the devices were getting treated as new devices even though they were already mounted. For /boot I got a window showing the contents, for other file systems I got prompted for the luks key needed to access them. This was with DeviceKit-disks-003-7.fc11.x86_64 .