From ArchWiki
Revision as of 11:09, 20 July 2012 by Madchine (talk | contribs) (Added: 'Structure')
Jump to: navigation, search

Tango-view-fullscreen.pngThis article or section needs expansion.Tango-view-fullscreen.png

Reason: please use the first argument of the template to provide a brief explanation. (Discuss in Talk:Polkit#)

From PolicyKit Library Reference Manual:

PolicyKit 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. PolicyKit is specifically targeting applications in rich desktop environments on multi-user UNIX-like operating systems. It does not imply or rely on any exotic kernel features.

PolicyKit 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.

PolicyKit 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.

PolicyKit vs. polkit

In the development of PolicyKit, major changes were introduced around version 0.92. In order to make the distinction clear between the way the old and the new versions worked, the new ones are referred to as 'polkit' rather than PolicyKit. Searching for PolicyKit on the web will mostly point to outdated documentation and lead to confusion and frustration, e.g. [1]. The main distinction between PolicyKit and polkit is the abandonment of single-file configuration in favour of directory-based configuration, i.e. there is no PolicyKit.conf.


PolicyKit definitions can be divided into three kinds:

  • Actions are defined in XML 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)
  • Policies ared 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, a policy 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 to determine who is an administrative user. Common definitions are 'only root user' or 'all members of wheel' (the Arch default)


Please note: to correct issues with automount and shutdown, please check the ConsoleKit page.

Practical examples

How to let all users in the group wheel have the same privileges as root (so you do not have to enter the root password, but the wheel user's password):

Installing polkit-use-wheel-groupAUR from the AUR will create this file automatically.

Create the following file:

Note: Higher numbers are prioritized over lower numbers.

To let users alice and bob perform all PackageKit actions (but not necessarily other PolicyKit actions), create the following file:

[Let Wheel Use PackageKit]
Note: You can use the command pkaction to list all actions defined in your system.