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

   Files shipped with PolicyKit and 3rd party packages (e.g. under package
   manager control) typically have comments (such as "DO NOT EDIT THIS
   FILE, it will be overwritten on update") telling the system
   administrator that changes will be overwritten on update.


   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 is read from files in the
   /etc/polkit-1/localauthority.conf.d directory. All files are read in
   lexigraphical order (using the C locale) meaning that later files can
   override earlier ones. 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 (also commonly known as a ini file) with a single
   group called [Configuration]. 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:, groups of users are specified by prefixing with
   unix-group:, and netgroups of users are specified with unix-netgroup:.
   See the section called "EXAMPLES" for an example of a configuration


   The Local Authority reads files with .pkla extension from all
   directories located inside the /etc/polkit-1/localauthority and
   /var/lib/polkit-1/localauthority directories. By default, the following
   sub-directories are installed.

       `-- localauthority
           |-- 10-vendor.d
           |-- 20-org.d
           |-- 30-site.d
           |-- 50-local.d
           `-- 90-mandatory.d


       `-- localauthority
           |-- 10-vendor.d
           |-- 20-org.d
           |-- 30-site.d
           |-- 50-local.d
           `-- 90-mandatory.d

   The /etc/polkit-1/localauthority hierarchy is inteded for local
   configuration and the /var/lib/polkit-1/localauthority is intended for
   3rd party packages.

   Each .pkla file contains one or more authorization entries. If the
   underlying filesystem supports file monitoring, the Local Authority
   will reload information whenever .pkla files are added, removed or

   Each directory is intended for a specific audience

       Intended for use by the OS vendor.

       Intended for the organization deploying the OS.

       Intended for the site deploying the system.

       Intended for local usage.

       Intended for the organization deploying the OS.

   and new directories can be added/removed as needed.

   As to regards to the content, 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. For example, if the organization is "Acme Corp"
   needs to modify policy for the product "Frobnicator", a name like
   com.acme.frobnicator.pkla would be suitable.


   Each group in a .pkla file must have a name that is unique within the
   file it belongs to. The following keys are are recognized:

       A semi-colon separated list of globs to match identities. Each glob
       should start with unix-user: or unix-group: to specify whether to
       match on a UNIX user name or a UNIX group name. Netgroups are
       supported with the unix-netgroup: prefix, but cannot support glob

       A semi-colon separated list of globs to match action identifiers.

       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 .policy
       files used to define actions, e.g.  yes, no, auth_self,
       auth_self_keep, auth_admin and auth_admin_keep.

       Like ResultActive but instead applies to subjects in inactive local

       Like ResultActive but instead applies to any subject.

       A semi-colon separated list of key/value pairs (of the form
       key=value) that are added to the details of authorization result on
       positive matches.

   All keys specified above are required except that only at least one of
   ResultAny, ResultInactive and ResultActive must be present. The
   ReturnValue key is optional.


   When a Mechanism requests services from the Authority to check if a
   given Subject is authorized for a given Action, the authorization
   entries discussed above are consulted using the following algorithm.

   The authorization entries from all .pkla files are ordered using the
   following rules. First all the basename of all sub-directories (e.g.
   30-site.d) from both the /etc/polkit-1/localauthority and
   /var/lib/polkit-1/localauthority directories are enumerated and sorted
   (using the C locale). If a name exists in both /etc and /var, the one
   in /etc takes precedence. Then all .pkla files are read in order from
   this list of sub-directories. For each .pkla file, authorizations from
   each file are appended in order resulting in an ordered list of
   authorization entries.

   For example, given the following files



   the evaluation order of the .pkla files is:

    1. 10-desktop-policy.pkla

    2. 01-some-changes-from-a-subvendor.pkla

    3. (the /var one)

    4. (the /etc one)

   When the list of authorization entries has been calculated, the
   authorization check can be made. 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 order. If
   the authorization check matches the data from the authorization check,
   then the authorization result from RequireAny, RequireInactive or
   RequireActive is used and ReturnValue is added to the authorization

   Finally, the authorization entries are consulted using the user
   identity in the same manner.

   Note that processing continues even after a match. This allows for
   socalled "negative authorizations", see the section called "EXAMPLES"
   for further discussion.


   The following .conf file


   specifies that any user in the staff UNIX group can be used for
   authentication when administrator authentication is needed. This file
   would typically be installed in the /etc/polkit-1/localauthority.conf.d
   directory and given the name 60-desktop-policy.conf to ensure that it
   is evaluted after the 50-localauthority.conf file shipped with
   PolicyKit. If the local administrator wants to override this (suppose
   60-desktop-policy.conf was shipped as part of the OS) he can simply
   create a file 99-my-admin-configuration.conf with the following content


   to specify that only the users lisa and marge can authenticate when
   administrator authentication is needed.

   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]

   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]

   and make sure this authorization entry is after the first one.


   Written by David Zeuthen <> with a lot of help from
   many others.


   Please send bug reports to either the distribution or the polkit-devel
   mailing list, see the link on how to



More Linux Commands

Tcl_SetErrorCodeVA(3) - retrieve or record information about
The Tcl_SetReturnOptions and Tcl_GetReturnOptions routines expose the &amp;#9474; same capabilities as the return and catch commands, respectively, in &amp;#9474; the f

Bootloader::Core::NONE(3pm) - library for blank configuratio
$obj_ref = Bootloader::Core::NONE-&gt;new (); Creates an instance of the Bootloader::Core::NONE class. $files_ref = Bootloader::Core::NONE-&gt;ListFiles (); Returns t

key.dns_resolver(8) - Upcall for request-key to handle dns_r
This program is invoked by request-key on behalf of the kernel when kernel services (such as NFS, CIFS and AFS) want to perform a hostname lookup and the kernel

htole16(3) - convert values between host and big-/little-end
These functions convert the byte encoding of integer values from the byte order that the current CPU (the host) uses, to and from little-endian and big-endian b

ld_errno(3) - LDAP protocol error handling routines.........
The ldap_err2string() routine provides short description of the various codes returned by routines in this library. The returned string is a pointer to a static

pnmarith(1) - perform arithmetic on two PNM images (ManPage)
This program is part of Netpbm(1) Starting with Netpbm 10.3, pnmarith is obsolete. Use pamarith(1) instead. pamarith is backward compatible with pnmarith except

systemd-random-seed.service(8) Load and save the system rand
systemd-random-seed.service is a service that restores the random seed of the system at early-boot and saves it at shutdown. See random(4) for details. Saving/r

cursor(3form) - position a form window cursor (Man Page)....
cursor.3form - The function pos_form_cursor restores the cursor to the position required for the forms driver to continue processing requests. This is useful af

getutent(3) - access utmp file entries - Linux manual page
New applications should use the POSIX.1-specified utmpx versions of these functions; see CONFORMING TO. utmpname() sets the name of the utmp-format file for the

glutFullScreen(3) - requests that the current window be made
glutFullScreen requests that the current window be made full screen. The exact semantics of what full screen means may vary by window system. The intent is to m

ldapurl(1) - LDAP URL formatting tool - Linux manual page...
ldapurl is a command that allows to either compose or decompose LDAP URIs. When invoked with the -H option, ldapurl extracts the components of the ldapuri optio

gnutls_x509_crq_set_basic_constraints(3) - API function.....
This function will set the basicConstraints certificate extension. RETURNS On success, GNUTLS_E_SUCCESS (0) is returned, otherwise a negative error value. SINCE

We can't live, work or learn in freedom unless the software we use is free.