Difference between revisions of "Polkit"

From ArchWiki
Jump to: navigation, search
(remove PolicyKit section, as the configuration changed a lot over the time)
(merge document and see also sections)
Line 157: Line 157:
For a more thorough introduction and more advanced features, including globbing, see the man pages of polkit and pklocalauthority
For a more thorough introduction and more advanced features, including globbing, see the man pages of polkit and pklocalauthority:
== See also ==
man polkit
* [http://www.freedesktop.org/software/polkit/docs/latest/polkit.8.html Polkit manual page]
man pklocalauthority
==See also==
* [[ConsoleKit]]

Revision as of 14:16, 1 September 2013

Tango-view-refresh-red.pngThis article or section is out of date.Tango-view-refresh-red.png

Reason: Now we have systemd and javascript in rule config (Discuss in Talk:Polkit#)
Template:Article summary start

Template:Article summary text Template:Article summary heading Template:Article summary wiki Template:Article summary end From polkit homepage:

polkit is an application-level toolkit for defining and handling the policy that allows unprivileged processes to speak to privileged processes: It is a framework for centralizing the decision making process with respect to granting access to privileged operations for unprivileged applications.

Polkit is used for controlling system-wide privileges. It provides an organized way for non-privileged processes to communicate with privileged ones. In contrast to systems such as sudo, it does not grant root permission to an entire process, but rather allows a finer level of control of centralized system policy.

Polkit works by delimiting distinct actions, e.g. running GParted, and delimiting users by group or by name, e.g. members of the wheel group. It then defines how – if at all – those users are allowed those actions, e.g. by identifying as members of the group by typing in their passwords.


Polkit can be installed with the package polkit, available in the official repositories.

Authentication agents

The polkit package contains a textual authentication agent called 'pkttyagent', which used as a general fallback. If you are using a graphical environment, make sure that a graphical authentication agent installed and autostarted on login. Cinnamon, GNOME, GNOME Flashback, KDE and LXDE have an authentication agent already. In other desktop environments, you have to choose one of the following implementations:

  • lxpolkit: autostart everywhere except in GNOME and KDE by default.
  • polkit-gnome: autostart in GNOME Flashback by default.
  • polkit-kde: autostart in KDE by default.


PolicyKit definitions can be divided into three kinds:

  • Actions are defined in XML .policy files located in /usr/share/polkit-1/actions. Each action has a set of default permissions attached to it (e.g. you need to identify as an administrator to use the GParted action). The defaults can be overruled but editing the actions files is NOT the correct way (see askubuntu.com for a bad example)
  • Authorities are defined in INI-like .pkla files. They are found in two places: 3rd party packages can use /var/lib/polkit-1 (though few if any do) and /etc/polkit-1 is for local configuration. The .pkla files designate a subset of users, refer to one (or more) of the actions specified in the actions files and determine with what restrictions these actions can be taken by that/those user(s). As an example, an authority file could overrule the default requirement for all users to authenticate as an admin when using GParted, determining that some specific user doesn't need to. Or isn't allowed to use GParted at all.
  • Admin identities are set in /etc/polkit-1/localauthority.conf.d One of the basic points of using PolicyKit is determining whether or not a user needs to authenticate (possibly as an administrative user) or not in order to get permission to carry out the action. PolicyKit therefore has a specific configuration for deciding if the user trying to carry out an action is or is not an administrative user. Common definitions are 'only root user' or 'all members of wheel' (the Arch default).


Each action is defined in an <action> tag in a .policy file. The org.archlinux.pkexec.gparted.policy contains a single action and looks like this:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE policyconfig PUBLIC
 "-//freedesktop//DTD PolicyKit Policy Configuration 1.0//EN"

  <action id="org.archlinux.pkexec.gparted">
    <message>Authentication is required to run the GParted Partition Editor</message>
    <annotate key="org.freedesktop.policykit.exec.path">/usr/sbin/gparted</annotate>
    <annotate key="org.freedesktop.policykit.exec.allow_gui">true</annotate>


The attribute id is the actual command sent to dbus, the message tag is the explanation to the user when authentification is required and the icon_name is sort of obvious.

The default tag is where the permissions or lack thereof are located. It contains three settings: allow_any, allow_inactive, and allow_active. Inactive sessions are generally remote sessions (SSH, VNC, etc.) whereas active sessions are logged directly into the machine on a TTY or an X display. Allow_any is the setting encompassing both scenarios.

For each of these settings the following options are available:

  • no: The user is not authorized to carry out the action. There is therefore no need for authentification.
  • yes: The user is authorized to carry out the action without any authentification.
  • auth_self: Authentication is required but the user need not be an administrative user.
  • auth_admin: Authentication as an administrative user is require.
  • auth_self_keep: The same as auth_self but, like sudo, the authorization lasts a few minutes.
  • auth_admin_keep: The same as auth_admin but, like sudo, the authorization lasts a few minutes.

These are default setting and unless overruled in later configuration will be valid for all users.

As can be seen from the GParted action, users are required to authenticate as administrators in order to use GParted, regardless of whether the session is active or inactive.


Authorizations that overrule the default settings are laid out in a set of directories as described above. For all purposes relating to personal configuration of a single system, only /etc/polkit-1/localauthority/50-local.d should be used. The authority files are read in alphabetical/numerical order, where later files take precedence, so that one configuration file can be relied upon to overrule another, e.g.


The layout of the .pkla files is fairly self-explanatory:

[Ban users jack and jill from using gparted]

An authorization needs to be preceded by a heading enclosed in square brackets. The follows an identification with pairs of unix-user or unix-group and the name. Use semicolons to separate the pairs to include more than one user or group. The designating name of the action is the one from the action's id attribute in /usr/share/polkit-1/actions. The three Result-settings mirror those from the action definition. Here we have overruled the default auth_admin setting and disallowed jack and jill from running gparted.

Admin identities

Like the authorities files, configuration works by letting the last read file take precedence over earlier ones. The default configuration for admin identities is contained in the file 50-localauthority.conf so any changes to that configuration should be made by copying the file to, say, 60-localauthority.conf and editing that file.

# Configuration file for the PolicyKit Local Authority.
# DO NOT EDIT THIS FILE, it will be overwritten on update.
# See the pklocalauthority(8) man page for more information
# about configuring the Local Authority.


The only part to edit (once copied) is the right part of the equation: As whom should a user authenticate when asked to authenticate as an administrative user? If she herself is a member of the group designated as admins, she only need enter her own password. If some other user, e.g. root, is the only admin identity, she would need to enter in root's password. The format of the user identification is the same as the one used in designating authorities. The Arch default is to make all members of the group wheel administrators.

Action groups

The actions available to you via PolicyKit will depend on the packages you have installed. Some are used in multiple desktop environments (org.freedesktop.*), some are DE-specific (org.gnome.*) and some are specific to a single program (org.archlinux.pkexec.gparted.policy). The commandpkaction lists alle the actions defined in /usr/share/polkit-1/actions for quick reference.

To get an idea of what PolicyKit can do, here are a few commonly used groups of actions:

  • ConsoleKit (org.freedesktop.consolekit.policy) actions regulated by PolicyKit include shutting down and restarting, including when other users may still be logged in.
  • Upower (org.freedesktop.upower.policy) actions regulated by PolicyKit include suspending and hibernating.
  • Udisks2 (org.freedesktop.udisks2.policy) actions regulated by PolicyKit include mounting file systems and unclocking encrypted devices.
  • NetworkManager (org.freedesktop.NetworkManager.policy) actions regulated by PolicyKit include turning on and off the network, wifi, or mobile broadband.


PolicyKit operates on top of the exisiting permissions systems in linux -- group membership, administrator status -- it does not replace them. The example above prohibited the user jack from using the GParted action, but it does not preclude him running GParted by some means that do not respect PolicyKit, e.g. the command line. Therefore it's probably better to use PolicyKit to expand access to priviledged services for unpriviledged users, rather than to try using it to curtail the rights of (semi-)privileged users. For security purposes, the sudoers file is still the way to go.


Suspend and hibernate

To give the users in the group power the permission to suspend or hibernate using Upower, it is sufficient to create an authority file /etc/polkit-1/localauthority/50-local.d/org.freedesktop.upower.pkla that allows group members the use of the two actions:

[Suspend/hibernate permissions]

Since the action groups change occasionally, it might be useful to check the documentation in /usr/share/polkit-1/actions/org.freedesktop.upower.policy to make sure that the actions are correct.

Mounting USB drives

To grant users in the storage group the permission to mount/unmount/eject disks via Udisks2, the following lines can be written into a file /etc/polkit-1/localauthority/50-local.d/org.freedesktop.udisks2.pkla:

[Storage Permissions]

Workaround to mount filesytems by user in group storage without password

the following lines can be written into a file /etc/polkit-1/rules.d/10-udisks2.rules:

// Allow udisks2 to mount devices without authentication
// for users in the "storage" group.
polkit.addRule(function(action, subject) {
 if ((action.id == "org.freedesktop.udisks2.filesystem-mount-system" ||
      action.id == "org.freedesktop.udisks2.filesystem-mount") &&
subject.isInGroup("storage")) {
       return polkit.Result.YES;
polkit.addRule(function(action, subject) {
   if ((action.id == "org.freedesktop.udisks.filesystem-mount-system-internal") &&
subject.isInGroup("storage")) {
       return polkit.Result.YES;

For a more thorough introduction and more advanced features, including globbing, see the man pages of polkit and pklocalauthority

See also