We'll see | Matt Zimmerman

a potpourri of mirth and madness

Navigating the PolicyKit maze

I’ve written a simple application which will automatically extract media from CDs and DVDs when they are inserted into the drive attached to my server. This makes it easy for me to compile all of my media in one place and access it anytime I like. The application uses the modern udisks API, formerly known as DeviceKit-disks, and I wrote it in part to learn get some experience working with udisks (which, it turns out, is rather nice indeed).

Naturally, I wanted to grant this application the privileges necessary to mount, unmount and eject removable media. The server is headless, and the application runs as a daemon, so this would require explicit configuration. udisks uses PolicyKit for authorization, so I expected this to be very simple to do. In fact, it is very simple, but finding out exactly how to do it wasn’t quite so easy.

The Internet is full of web pages which recommend editing /etc/PolicyKit/PolicyKit.conf. As far as I can tell, nothing pays attention to this file anymore, and all of these instructions have been rendered meaningless. My system was also full of tools like polkit-auth, from the apparently-obsolete policykit package, which kept their configuration in some other ignored place, i.e. /var/lib/PolicyKit. It seems the configuration system has been through a revolution or two recently.

In Ubuntu 10.04, the right place to configure these things seems to be /var/lib/polkit-1/localauthority, and this is documented in pklocalauthority(8). Authorization can be tested using pkcheck(1), and the default policy can be examined using pkaction(1).

I solved my problem by creating a file in /var/lib/polkit-1/localauthority/50-local.d with a .pkla extension with the following contents:

[Access to removable media for the media group]

This took effect immediately and did exactly what I needed. I lost quite some time trying to figure out why the other methods weren’t working, so perhaps this post will save the next person a bit of time. It may also inspire some gratitude for the infrastructure which makes all of this work automatically for more typical usage scenarios, so that most people don’t need to worry about any of this.

Along the way, I whipped up a patch to add a --eject option to the handy udisks(1) tool, which made it easier for me to test along the way.


Written by Matt Zimmerman

June 27, 2010 at 14:38

13 Responses

Subscribe to comments with RSS.

  1. Configuration outside /etc? Sigh.


    June 27, 2010 at 16:16

  2. “The Local Authority reads files with .pkla extension from all directories located inside the /etc/polkit-1/localauthority and /var/lib/polkit-1/localauthority directories.”

    So does this work if you put your file in /etc instead?

    Sam Morris

    June 27, 2010 at 17:49

  3. I want to backup all my CDs too, so I read your blog with interest. Though I find it astonishing how sucky this seems to be. Why is it a maze to simply mount a CD automatically? Why is it called policy and why a strange .pkla extension.

    How about sucking less?

    Can’t you accomplish the same with:

    while mount /media/cd
    ls /media/cd
    read -p “Press enter to read next disk”

    Kai Hendry

    June 27, 2010 at 18:02

    • It took a bit of figuring out because this part of the platform is in flux, but PolicyKit actually provides a very flexible and elegant solution to this particular problem. The word policy accurately describes this bit of configuration.

      And no, I can’t accomplish the same thing with a trivial shell script. :-)

      Matt Zimmerman

      June 27, 2010 at 21:13

  4. Can’t find your patch in the upstream bugzilla.


    June 28, 2010 at 07:27

  5. Thank you, thank you, thank you for your post. We need more blog posts about PolicyKit, as the documentation is confusing and out of date.


    June 28, 2010 at 10:32

  6. yes, there needs to be better docs on policykit and how distros implement it. i have wasted all day trying to figure out how to get gnome admin panels to accept my own authentication for admin privs since I am in the wheel group. to no success. since this appears to work for the package manager, i can only conclude that some apps just aren’t policy-kit compatible yet.


    July 10, 2010 at 23:40

  7. […] schnell, dass hier PolicyKit seine Finger im Spiel hat. Weiteres Suchen offenbarte mir schließlich eine Lösung, welche ich unter /etc/polkit-1/localauthority/50-local.d/plugdev.plka platzierte: [Access to […]

  8. Sorry to dig up an old-ish thread, but this was pointed out by your first two commenters and apparently ignored. Many people do not read the comment threads, so if you do not update the original post then these people will end up following bad advice. Configuration files on Linux belong in /etc, or in the user’s home folder. You said “the right place to configure these things seems to be…”; The correct answer here is “/etc/polkit-1/”. You also said “this is documented in pklocalauthority(8)”, and you are correct. This man page is where I found the above information. I have tested this on my own machine, and it is working as expected. The location in /var is intended for packages to install PolicyKit rules, where the location in /etc is intended for the admin to manage local PolicyKit rules.

    Silver Knight

    April 22, 2011 at 04:11

  9. […] a nawet jeśli coś jest, to często są to stare i nieaktualne dane. Ostatecznie pomógł ten wpis nt. PolicyKit i opis PolicyKit na wiki Arch. Po kolei, czyli najpierw wyświetlanie dostępnych w systemie akcji […]

Comments are closed.

%d bloggers like this: