Authorization Types

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

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:

Authentication

The user always has to authenticate

One Shot Authentication

The authentication is bound to the instance of the program currently running. Once the program is restarted, the user is required to authenticate again.

Keep Session Authentication

The authentication dialog box offers a check button Remember authorization for this session. If checked, the authentication is valid until the user logs out.

Keep Indefinitely Authentication

The authentication dialog box offers a check button Remember authorization. If checked, the user has to authenticate only once.

Explicit Privileges

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.