9.2.1 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 autho-
rized, 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.
9.2.2 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.
PolicyKit
83