Every time a PolicyKit-enabled process carries out a privileged operation, PolicyKit is asked whether this process is entitled to do so. The answer PolicyKit gives depends on the policy defined for this process. It can be “yes”, “no”, or “authentication needed”. By default, a policy contains “implicit” privileges, which automatically apply to all users. It is also possible to specify “explicit” privileges which apply to a specific user.
Implicit privileges can be defined for any, active, and inactive sessions. An active session is the one in which you are currently working. It becomes inactive when you switch to another console for example. When setting implicit privileges to “no”, no user is authorized, whereas “yes” authorizes all users. However, in most cases it is useful to demand authentication.
A user can either authorize by authenticating as root
or by
authenticating as self. Both authentication methods exist in four
variants:
The user always has to authenticate
The authentication is bound to the instance of the program currently running. Once the program is restarted, the user is required to authenticate again.
The authentication dialog box offers a check button
. If checked, the authentication is valid until the user logs out.The authentication dialog box offers a check button
. If checked, the user has to authenticate only once.Explicit privileges can be granted to specific users. They can either be granted without limitations, or, when using constraints, limited to an active session and/or a local console.
It is not only possible to grant privileges to a user, a user can also be blocked. Blocked users will not be able to carry out an action requiring authorization, even though the default implicit policy allows authorization by authentication.