![]() |
![]() |
![]() |
PolicyKit Reference Manual | ![]() |
---|
pklocalauthoritypklocalauthority — PolicyKit Local Authority |
The Local Authority is the default PolicyKit authority implementation. Configuration for the Local Authority and information pertaining to authorization decisions are read from local files on the disk. One design goal of the Local Authority is to split configuration items into separate files such that 3rd party packages and users won't conflict trying to edit the same files. This policy also ensures smooth upgrades when distributing PolicyKit using a package management system.
PolicyKit makes a distinction between user authentication (to make the user in front of the system prove he really is the user) and administrator authentication (to make the user in front of the system prove he really is an administrator). Since various operating systems (or even flavors of the same operating system) has different ways of defining "administrator", the Local Authority provides a way to specify what "administrator authentication" means.
By default, "administrator authentication" is defined as asking for the root password. Since some systems, for usability reasons, don't have a root password and instead rely on a group of users being member of an administrative group that gives them super-user privileges, the Local Authority can be configured to support this use-case as well.
Configuration for the Local Authority are read from files in
the /etc/polkit-1/localauthority.conf.d
directory. The file 50-localauthority.conf
contains the settings provided by the OS vendor. Users and 3rd
party packages can drop configuration files with a priority
higher than 60 to change the defaults. The configuration file
format is simple. Each configuration file is a key
file with a single Configuration
group. Only a single key, AdminIdentities
is
read. The value of this key is a semi-colon separated list of
identities that can be used when administrator authentication is
required. Users are specified by prefixing the user name with
unix-user:
and groups of users are specified
by prefixing with unix-group:
.
The Local Authority reads files with .pkla
from the following directories
/var/lib/polkit-1/ `-- localauthority |-- 10-vendor.d |-- 20-org.d |-- 30-site.d |-- 50-local.d `-- 90-mandatory.d
Each .pkla
contains one or more
authorization entries. If the underlying filesystem supports
file monitoring, the Local Authority will reload information
whenever changes occur.
Each directory is intended for a specific audience
10-vendor.d |
Reserved for the Operating System vendor. |
20-org.d |
Reserved for the organization deploying the system. |
30-site.d |
Reserved for site deploying the system. |
50-local.d |
Reserved for local usage. |
90-mandatory.d |
Reserved for the organization deploying the system. |
Each .pkla
file is a standard key
file and contains key/value pairs in one or more
groups with each group representing an authorization entry.
A .pkla
file MUST be named by using a
scheme to ensure that the name is unique, e.g. reverse DNS
notation or similar.
Each group in a .pkla
must have a name that
is unique within the file it belongs to. The following keys are
required in each group
Identity |
A semi-colon separated list of globs to match identities. Each glob
should start with |
Action |
A semi-colon separated list of globs to match action identifiers. |
ResultActive |
The result to return for subjects in an active local
session that matches one or more of the given identities.
Allowed values are similar to what can be used in
the defaults section
of |
ResultInactive |
Like ResultActive but instead applies to subjects in inactive local sessions. |
ResultAny |
Like ResultActive but instead applies to any subject. |
All keys specified above are required except that only at least one of RequireAny, RequireInactive and RequireActive is present.
Whenever a Mechanism does an authorization check to check if a given Subject is authorized for a given action, the authorization entries discussed above are consulted in the following order. First, the user of the Subject is determined and the groups that the user belongs are looked up.
For each group identity, the authorization entries are consulted in the standard lexigraphical order (using standard lexicographical sorting (using the standard C locale) of file names and appearance of each group in each file). If the authorization check matches the data from the authorization check, then the authorization result from RequireAny, RequireInactive or RequireActive is used. Finally, the authorization entries are consulted using the user identity.
Note that processing continues even after a match. This allows for socalled “negative authorizations”, see the section called “EXAMPLES” for further discussion.
The following .pkla
file grants
authorization to all users in the staff
group
for actions matching the
glob com.example.awesomeproduct.*
provided
they are in an active session on the local console:
[Normal Staff Permissions] Identity=unix-group:staff Action=com.example.awesomeproduct.* ResultAny=no ResultInactive=no ResultActive=yes
If the users homer
and grimes
are member of
the staff
group but policy requires that an
administrator needs to authenticate every time authorization for
any action
matching com.example.awesomeproduct.*
is
required, one would add
[Exclude Some Problematic Users] Identity=unix-user:homer;unix-user:grimes Action=com.example.awesomeproduct.* ResultAny=no ResultInactive=no ResultActive=auth_admin
and make sure this authorization entry is after the first one.
Please send bug reports to either the distribution or the polkit-devel mailing list, see the link http://lists.freedesktop.org/mailman/listinfo/polkit-devel on how to subscribe.