PolicyKit, keeping you in check

On my default KDE 4.1.x ( unstable ) install, mounting DVDs or CDs has never worked. Tonight i decided to find out why. The problem that occurs is that when i insert a DVD, CD or any other removable media, i can't access it ( without doing an old school mount from command line ). When i click on the media in Dolphin, i get and error along the lines of "org.freedesktop.hal.storage.mount-removable no <-- (action, result)". Turns out this is a PolicyKit issue, so i decided to actually find out more... first here is the fix:

Open up a file editor as root and edit this file: /etc/PolicyKit/PolicyKit.conf

My file had not much other than a nice little header and the basic xml:

<config version="0.1">

</config>

Adding the following lines inside of this config tag fixes the problem:

<match action="org.freedesktop.hal.storage.mount-removable">

<return result="yes" />

</match>

Another thing that i had to do ( you might too ) is launch an instance of a ConsoleKit session. I did this by running from krunner:

ck-launch-session

And that was it, thereafter i could install my newly purchased Command & Conquer - The First Decades DVD ( thanks Wine!!! ). As my wife took control of the other laptop to play the games that i just installed, i decided to find out what exactly this PolicyKit does, and why it is needed.

What was always my understanding of how Linux systems allow users to access certain devices/services, was by pushing users into a group containing those services. I might be way behind the times on this, since i am an openSUSE user, and the PolicyKit page maintains that Debian systems rely on group membership, while RedHat systems provide a mechanism where a local user can enter a root password to access these services. There are many problems with both of these methods, namely:

• Group membership is set no matter what. If you are in CDROM group, you have access to everything to do with CDROM, there is no deeper level of control.
•  Using sudo to access an application means ( sadly ) that all the libraries linked to that application are run as root. Other than needing to store preferences for these libraries as root user, this also might open up some seriously large security holes. Imagine we need to sudo our dvd writing app, and it turns out that its written in GTK using pnglib. Now some issue is found in pnglib or GTK that, if run as root, can really allow malicious code to be executed remotely. You get the point.
• There are different ways of doing this policy management. Say you're writing a new window manager like, and you need access to certain privileges. But you want your window manager to work on all distributions. How do you deal with the differences, case based programming sucks.

Enter PolicyKit. It basically defines a way for applications to request access to different services, devices, etc. PolicyKit defines the existence of Mechanisms and Policy Agents. A typical user will interact with the agent. The Agent might request access, through some form of Inter-Process Communication ( IPC ) - now days D-Bus, to a system Mechanism, for example HAL or NetworkManager. The action requested might be something like requesting to mount a removable media. PolicyKit lets the Mechanism know whether the Agent should be allowed this access.

Another great thing about PolicyKit, is that the policies are defined in XML, something completely underrated and underused. It's simple to read and understand, and very simple to add your own policies. And of course, with libraries like TinyXML, it's really simple to code. You can find more details about PolicyKit here. As systems like Windows start their venture on User Account Control ( and screw it up the first time ), Linux is making a huge move forward to develop a long term, extensible manner of dealing with these problems. The innovation never stops!