Unmounting removable media mounted by different user

English Applications
1

I have here a multi-seat machine which admits removable media (USB sticks, SD cards, etc.) Any user with physical access to the ports/slots can mount and use one of those. What I would like is for any other user to be able to unmount a device mounted by another user, who may or may no longer be logged in.

Currently, on attempting to unmount such a device, an “authentication required” dialogue appears asking for the root password–under details, the responsible policy is announced as “org.freedesktop.udisks.filesystem-unmount-others”.

Clearly, what is needed is a configuration change for that policy from “auth_admin” to, in my case, “yes”. Now the question is where should I change this so that it takes effect?

As a KDE4 user, a first and sort of obvious stop is System Settings > Actions Policy. Unfortunately, that’s a bit of a non-starter for now (but certainly looking forward to see it working sometime).

That having failed, I proceed to the relevant documentation for OpenSUSE with the intention of finding out how to change the implicit privileges as described in section 9.3 of the aforementioned documentation. Therein it is stated that “there are two PolicyKit versions available in parallel with openSUSE: the “old” PolicyKit and the “new” polkit version (polkit-1)” (great! :slight_smile: but it is not stated which controls what, so I take a potshot and run as root:

polkit-action --set-defaults-active org.freedesktop.udisks.filesystem-unmount-others yes

Which results in a rather discouraging announcement of:

Cannot find policy file entry for action id 'org.freedesktop.udisks.filesystem-unmount-others'

That didn’t seem to work, so I hazard a guess that the “new” polkit might be involved, as intimated by the documentation, which directs one to http://hal.freedesktop.org/docs/polkit/, a page labelled as “PolicyKit Reference Manual” and consisting mostly of the API description (just in case I might ever wish to write a PolicyKit client?). Anyhow, at the bottom of that page one finds links to a couple of man pages, so I open the one for polkit(8). Towards the bottom of that page there is a section on “declaring actions” which points to the directory /usr/share/polkit-1/actions as the place where things happen, so I look in that directory on the offending machine and find the file /usr/share/polkit-1/actions/org.freedesktop.udisks.policy which I open–rather encouraging, the section for org.freedesktop.udisks.filesystem-unmount-others shows the same configuration that appears in KDE’s System Settings > Actions Policy, so I go and change that. After applying the changes I open System Settings and observe that it reflects the new values, as does running this:

# pkaction --verbose --action-id org.freedesktop.udisks.filesystem-unmount-others
org.freedesktop.udisks.filesystem-unmount-others:
  description:       Unmount a device mounted by another user
  message:           Authentication is required to unmount devices mounted by another user
  vendor:            The udisks Project
  vendor_url:        http://udisks.freedesktop.org/                                                                         
  icon:              drive-removable-media                                                                                  
  implicit any:      no                                                                                                     
  implicit inactive: no                                                                                                     
  implicit active:   yes

Unfortunately, attempting to unmount another user’s device still does not work: the authorisation required dialogue still pops up. Note that every attempt is carried out after both the mounter and the unmounter users have logged out, then logged back in, then the mounter mounts, and the other user attempts to unmount.

Ok, so I am not making much progress so I move on to the next option, even if I think it’s less than ideal: explicit privileges. I proceed according to section 9.3.2.2. Modifying Configuration Files for Explicit Privileges of the OpenSUSE docs, and modify the file /etc/PolicyKit/PolicyKit.conf so that it now includes the lines:


    <match action="org.freedesktop.udisks.filesystem-unmount-others">
      <return result="yes" />
    </match>

I try yet once again. No joy.

Google seems to know about plenty of problems with PolicyKit configuration but not many solutions. Is it that I am missing something, doing something wrong, or the whole blasted thing simply does not work, or what?

Any suggestions, ideas, guesses, commentary, philosophical ramblings, flames, football scores, local newspaper clippings, pen1s enlargement offers, misrouted emails, or State secrets are warmly welcome. Not that I am frustrated or anything. :stuck_out_tongue:

2

It is really hard for mortals to fully understand if you withhold details like the OS and KDE version you are using.

I would be concerned about the damage that could be caused by allowing users to initiate a forced unmount of media that was in use.
Are you using automount or allowing users to manually mount? Do you have fstab entries for the removable media?
Have you thought about a script in ~/.kde4/shutdown/ to umount at logout?

3

On 09/27/2011 09:36 PM, licehunter wrote:
>
> I have here a multi-seat machine which admits removable media (USB
> sticks, SD cards, etc.) . . . Any suggestions, ideas, guesses

what happens if you just remove the device?
i would expect it to not be harmful to the running system or to the
device itself…

BUT, before you test my guess, read the caveat in my sig…

another way to handle it is fire, furlough, place on administrative
leave without pay, or just execute the next user who leaves their device
plugged in…

the word will get around pretty quickly and you won’t have to worry
about it anymore…

btw: i know lots of state secrets–but none are included in this posting…

–
DD
Caveat
openSUSE®, the “German Automobiles” of operating systems

4

On 2011-09-27 22:12, DenverD wrote:

> what happens if you just remove the device?
> i would expect it to not be harmful to the running system or to the
> device itself…

It could be.

The desktop should probably umount everything it mounted automatically when
the user logs out, or at least, warn about it.

By the way, the mount option “users” serves precisely to allow other users
to umount things mounted by others. Don’t ask me how to tell the desktop to
use that option.

–
Cheers / Saludos,

Carlos E. R.
(from 11.4 x86_64 “Celadon” at Telcontar)

5

Google seems to know about plenty of problems with PolicyKit configuration but not many solutions. Is it that I am missing something, doing something wrong, or the whole blasted thing simply does not work, or what?

Any suggestions, ideas, guesses, commentary, philosophical ramblings, flames, football scores, local newspaper clippings, pen1s enlargement offers, misrouted emails, or State secrets are warmly welcome. Not that I am frustrated or anything.

Hi licehunter

PolicyKit (and now PolKit) development is a fast moving platform, and a source of frustration for many. I’m using openSUSE 11.3, and remember reading the documentation as you have. I wish they would consolidate the configuration locations, and having 2 PolicyKit versions concurrently installed just adds to the confusion. I guess it was for backwards compatibility with various desktop environments.

Anyway, from quick experimentation on my part with a memory stick, another user account, an editor, and some ordinary household bleach, (forget the last one unless this doesn’t work) :), you’ll need to edit org.freedesktop.udisks.filesystem-unmount-others.pkla located in the /var/lib/polkit-1/localauthority/10-vendor.d directory. I went for it with

[org.freedesktop.udisks.filesystem-unmount-others]
Identity=unix-user:*
Action=org.freedesktop.udisks.filesystem-unmount-others
ResultAny=yes
ResultInactive=yes
ResultActive=yes

*You should just need to change the active console (last) entry to ‘yes’ for this to work the way you would like.

I then tested the policy change by starting a second desktop session with another user account, mounted my flash disk, then switched back to my regular user account and issued

udisks --unmount /dev/sdb1

It unmounted without issue. I repeated the mounting again, and unmounted via the KDE notifier (graphically), and again the unmounting worked perfectly, so this should work for you too.

6

On 09/28/2011 04:16 AM, deano ferrari wrote:
>
> udisks --unmount /dev/sdb1
>
> It unmounted without issue. I repeated the mounting again, and
> unmounted via the KDE notifier (graphically), and again the unmounting
> worked perfectly, so this should work for you too.

cool stuff, but:

note: read my sig caveat prior to beginning

wondering if my guess [the other user forgot stick, logged out and left
so just YANK it out and forget about it] was correct, wish you would try
(with 10-vendor.d directory in its original configuration), beginning
from your normal user account:

1 end session
2 log in as test user
3 mount flash disk
4 log out as test user leaving flash mounted
5 log in as normal user
6 observe results
a did DE ‘see’ the test users forgotten flash and complain?
b did it auto mount it (in mtab, myComputer,where…)?
c can normal user access flash disk WITHOUT taking steps to mount it,
become root in terminal, or launch a root powered file manager??
7 become root in a terminal
a is it possible to access it WITHOUT taking steps to mount it (in
other words it is mounted some way (probably auto-mounted when normal
user logged in)
b if it can be accessed as root (without mounting), can root then
unmount it, and remove it with no complaints?
c if it can not be accessed as root, nor unmounted as root, then do
8 physically remove flash without doing anything else and observe results
a did DE complain, error, freeze, take a break, go to the beach?
b did system complain, etc.?
c is computer hardware or software damaged in any way?
d is flash disk harmed in any way?
e can flash disk be used as normal (plug in, device notifier sees and
mount, etc etc etc?

if you house burns down or the flash disk is harmed, what if:

-do steps 1, 2, 3 and 4 above but BEFORE logging in as normal user
again–NOTICE the rogue stick still inserted and YANK it out…
-log in as yourself…then let the user who forgot their stick find it
laying near the machine, and let the worry about if it still works, or
not (i think it will)

however!! if i’m at work, walk up to a machine with no user logged in,
and find a flash disk attached (with no owner’s name etc on the stick,
and no idea who or when it was inserted), i might want to consider it a
possible means to try a system crack on MY user! and call security.

ymmv

[note: it is believed that the centrifuges of some nation’s (who i won’t
name nuclear facility) were physically damaged (destroyed) due to a
virus inserted into the centrifuges control circuits which came into the
facility via a thumb drive ‘found’ by a worker… (however, we all know
that that worker most likely used Windows, so…)]

–
DD
Caveat
openSUSE®, the “German Automobiles” of operating systems

7

1 end session
2 log in as test user
3 mount flash disk
4 log out as test user leaving flash mounted
5 log in as normal user
6 observe results
a did DE ‘see’ the test users forgotten flash and complain?
b did it auto mount it (in mtab, myComputer,where…)?

a. No, the regular user notifier sees the device, but it cannot be mounted, as the previous user mounted it, therefore at the desktop level, still owns it (as I expected)
The mount shows up as

/dev/sdb1 on /media/4C43-12E8 type vfat (rw,nosuid,nodev,uhelper=udisks,uid=1000,gid=100,shortname=mixed,dmask=0077,utf8=1)

b. I don’t have my DE (KDE4.6) configured to auto-mount, just notify. If it was, it would have failed (as expected).

c can normal user access flash disk WITHOUT taking steps to mount it,
become root in terminal, or launch a root powered file manager??
7 become root in a terminal
a is it possible to access it WITHOUT taking steps to mount it (in
other words it is mounted some way (probably auto-mounted when normal
user logged in)

Yes, if/when mounted by user-initiated action, root has r/w access as expected (kdesu dolphin…etc).

b if it can be accessed as root (without mounting), can root then
unmount it, and remove it with no complaints?

Yes, root can do anything, and once unmounted, it immediately disappears from the test user’s (if they originally mounted it) file manager (if open). No surprises yet.

The only thing users of a ‘multi-seat’ machine would need to be manually (physically?) aware of, is that once any usb-device is removed, it won’t be detected as available, until physically removed and connected again. This is obvious, (and no different), to single-user systems, unless one’s brain goes offline like mine from time-to-time… :slight_smile: …but a fresh user, could easily pysically see the device inserted and expect it to be reported, and available. The KDE4 desktop notifier doesn’t work this way (with devices previously ‘removed’), however, any user with CLI skills could re-mount (as user) with

udisks --mount /dev/sdb1
8

I still find the notion of people being able to remove someone else’s media when it may be in use leary.

If the users are mounting autodetected media via the device notifyer, it should umount when they logout. Unmounting of any user-mounted devices could be effected with a one-liner in the shutdown folder. e.g.

umount $(grep -n  $UID /etc/mtab |cut  -d" " -f2)

The drawback would be users who left the GUI session with <ctrl>+<backspace>, <ctrl>+<backspace>.
I am kind of inclined to the use of physical violence, or account suspension for uncooperative users.

9

If the users are mounting autodetected media via the device notifyer, it should umount when they logout.

It should be that way, but strangely, KDE (via udisks) did not seem to do the housekeeping, possibly because another user session was still active. There is added responsibility with shared removable media for users to do the right thing I guess.

If I’m not mistaken, when I executed

grep -n  $UID /etc/mtab |cut  -d" " -f2

as user nothing was returned, but as root I got

# grep -n  $UID /etc/mtab |cut  -d" " -f2
/
/proc
/sys
/sys/kernel/debug
/dev
/dev/shm
/dev/pts
/home
/sys/fs/fuse/connections
/windows/C
/sys/kernel/security
/proc/sys/fs/binfmt_misc
/media/4C43-12E8

Clearly, only the last entry is relevant here, especially if other sessions are still active!

10

This is expected if you have not mounted anything. What I did:
At a KDE session plug in a USB flash drive.
Mount it by clicking on the small icon within the Device Notifier in the System Tray.

ray@giulia:~/tmp> grep -n  $UID /etc/mtab |cut  -d" " -f2
/media/4AF3-BC0E
ray@giulia:~/tmp> umount $(grep -n  $UID /etc/mtab |cut  -d" " -f2)
ray@giulia:~/tmp> grep -n  $UID /etc/mtab |cut  -d" " -f2
ray@giulia:~/tmp>

If more than one user are sharing e.g. a data CD, they have to cooperate somehow.

11

On 09/28/2011 11:06 AM, eng-int wrote:
>I am kind of inclined to the use of physical violence, or account
> suspension for uncooperative users.

as a matter of system security i’d assume a “accidentally forgotten” usb
drive (of any kind) to be a potentially dangerous device which may
contain all sorts of evil stuff…kinda like walking off from a back
pack in an airport/cafe/train station…

and the OP’s quest to programmatically make such a device “ok…no
problem…easy to deal with, automatically” may not be the best, most
secure, way to solve the problem…

–
DD
openSUSE®, the “German Automobiles” of operating systems

12

This is expected if you have not mounted anything. What I did:
At a KDE session plug in a USB flash drive.

Yes, I had the device mounted (as you can see from output as root). Anyway, I tried it again as user and it correctly reported

dean@linux-n35n:~> grep -n  $UID /etc/mtab |cut  -d" " -f2
/media/4C43-12E8

It would probably be sensible to file a bug report for this, as logging out should take care of any udisks-based mounts for the respective user. Thanks for your input.

13

and the OP’s quest to programmatically make such a device “ok…no
problem…easy to deal with, automatically” may not be the best, most
secure, way to solve the problem…

AFAIU, the OP simply wished to be able to unmount a removable storage device that may have been mounted by another user.

14

maybe:

umount -l  $(grep -n  "\/media\/"  /etc/mtab |cut  -d" " -f2)

made executable suid would suit. Apart from the fights when one user umounts someone else’s USB stick during a crucial write.

15

On 2011-09-28 08:47, DenverD wrote:

> [note: it is believed that the centrifuges of some nation’s (who i won’t
> name nuclear facility) were physically damaged (destroyed) due to a virus
> inserted into the centrifuges control circuits which came into the facility
> via a thumb drive ‘found’ by a worker… (however, we all know that that
> worker most likely used Windows, so…)]

Not only windows, but a particular control system (scada?). It was a
targeted virus attack.

And the same country is said to be behind the attack to security company
Diginotar Certificate Authority, now out of business. They managed to
create hundreds of rogue SSL certificates (Google, Microsoft, Mozilla…).
Also using windows. The machines lacked antivirus and other security
measures. Bewildering.

> http://spectrum.ieee.org/riskfactor/telecom/security/diginotar-certificate-authority-breach-crashes-egovernment-in-the-netherlands/?utm_source=techalert&utm_medium=email&utm_campaign=091511

–
Cheers / Saludos,

Carlos E. R.
(from 11.4 x86_64 “Celadon” at Telcontar)

16

Fair enough:

**cat /etc/SuSE-release**
openSUSE 11.4 (x86_64)
VERSION = 11.4
CODENAME = Celadon

**uname -a**
Linux xxxxxx 2.6.37.6-0.7-desktop #1 SMP PREEMPT 2011-07-21 02:17:24 +0200 x86_64 x86_64 x86_64 GNU/Linux

**kde4-config --version**
Qt: 4.7.1
KDE Development Platform: 4.6.00 (4.6.0) "release 6"
kde4-config: 1.0

**rpm -qa |egrep -i "polkit|Policy"**
polkit-default-privs-0.1_201102151742-1.2.1.noarch
gnome-settings-daemon-polkit-datetime-2.32.1-4.1.x86_64
polkit-kde-agent-1-0.99.0-3.1.x86_64
polkit-0.99-5.6.1.x86_64
gconf-polkit-2.32.1-4.1.x86_64
libpolkit-qt-1-1-0.99.1-5.1.x86_64
libpolkit0-0.99-5.6.1.x86_64
PolicyKit-0.9-30.1.x86_64
polkit-kde-kcmmodules-1-0.98.1-3.2.x86_64
PolicyKit-doc-0.9-30.4.x86_64
polkit-gnome-0.99-6.1.x86_64
17

Hi Deano

Thank you so much for your helpful reply.

You can say that! :frowning:

Anyway, from quick experimentation on my part with a memory stick, another user account, an editor, and some ordinary household bleach, (forget the last one unless this doesn’t work) :), you’ll need to edit org.freedesktop.udisks.filesystem-unmount-others.pkla located in the /var/lib/polkit-1/localauthority/10-vendor.d directory.

Ah, that one! Indeed that makes sense, and you have understood exactly right what I’m trying to achieve.

I am not at the offending machine’s location right now, but I’ll go there and give your suggestion a try. I’m somehow confident that should work, but I’ll post here anyway once I’ve had a go.

Once again, many thanks for your help.

18

Hi Deano

You rock mate! rotfl!

Because of the setup I’m dealing with, I had to go for “ResultAny=yes” (and “Identity=unix-user:users”) but it’s all sweet now. Ta much.