Bug 489397 - DeviceKit-disks mounts on a desktop random partitions of a fixed storage
DeviceKit-disks mounts on a desktop random partitions of a fixed storage
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: DeviceKit-disks (Show other bugs)
rawhide
All Linux
low Severity medium
: ---
: ---
Assigned To: David Zeuthen
Fedora Extras Quality Assurance
: Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-03-09 16:31 EDT by Michal Jaegermann
Modified: 2013-03-05 22:58 EST (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-03-19 16:34:10 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
an output from "udevadm info --query all --name=/dev/dm-1" (1.13 KB, text/plain)
2009-03-15 20:47 EDT, Michal Jaegermann
no flags Details
an output from "udevadm info --query all --name=/dev/dm-2" (1.13 KB, text/plain)
2009-03-15 20:50 EDT, Michal Jaegermann
no flags Details
/etc/fstab used on a test installation (1.10 KB, text/plain)
2009-03-16 15:23 EDT, Michal Jaegermann
no flags Details
'devkit-disks --dump' before logging in (63.77 KB, text/plain)
2009-03-16 15:28 EDT, Michal Jaegermann
no flags Details
'devkit-disks --monitor-detail' while logging in (9.56 KB, text/plain)
2009-03-16 15:35 EDT, Michal Jaegermann
no flags Details
'devkit-disks --dump' after logging in (63.87 KB, text/plain)
2009-03-16 15:36 EDT, Michal Jaegermann
no flags Details

  None (edit)
Description Michal Jaegermann 2009-03-09 16:31:44 EDT
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.
Comment 1 David Zeuthen 2009-03-15 10:48:02 EDT
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.
Comment 2 Michal Jaegermann 2009-03-15 20:29:06 EDT
> 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.
Comment 3 Michal Jaegermann 2009-03-15 20:47:06 EDT
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
Comment 4 Michal Jaegermann 2009-03-15 20:50:08 EDT
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?
Comment 5 David Zeuthen 2009-03-16 12:34:29 EDT
Michal, what exactly are you complaining about in this bug? That some file system gets automounted and some doesn't?
Comment 6 Michal Jaegermann 2009-03-16 14:03:48 EDT
> 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.
Comment 7 David Zeuthen 2009-03-16 14:28:26 EDT
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
Comment 8 David Zeuthen 2009-03-16 14:29:09 EDT
Oh, and also please attach the contents of your /etc/fstab file. Thanks.
Comment 9 Michal Jaegermann 2009-03-16 15:23:47 EDT
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. :-)
Comment 10 Michal Jaegermann 2009-03-16 15:28:46 EDT
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).
Comment 11 Michal Jaegermann 2009-03-16 15:35:09 EDT
Created attachment 335411 [details]
'devkit-disks --monitor-detail' while logging in
Comment 12 Michal Jaegermann 2009-03-16 15:36:34 EDT
Created attachment 335413 [details]
'devkit-disks --dump' after logging in
Comment 13 Michal Jaegermann 2009-03-16 15:39:20 EDT
> 'polkit-auth --explicit-detail'

That command, as well as something like
'polkit-auth --user michal --explicit-detail', returns immediately with no output.
Comment 14 David Zeuthen 2009-03-16 16:25:48 EDT
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.
Comment 15 David Zeuthen 2009-03-19 16:34:10 EDT
(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
Comment 16 Michal Jaegermann 2009-03-23 13:51:35 EDT
It does "worksforme" after updates eventually showed up.  Thanks!
Comment 17 Bruno Wolff III 2009-03-23 15:49:35 EDT
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 .

Note You need to log in before you can comment on or make changes to this bug.