1PKLOCALAUTHORITY(8) pklocalauthority PKLOCALAUTHORITY(8)
2
3
4
6 pklocalauthority - PolicyKit Local Authority
7
9 The Local Authority is the default PolicyKit authority implementation.
10 Configuration for the Local Authority and information pertaining to
11 authorization decisions are read from local files on the disk. One
12 design goal of the Local Authority is to split configuration items into
13 separate files such that 3rd party packages and users won't conflict
14 trying to edit the same files. This policy also ensures smooth upgrades
15 when distributing PolicyKit using a package management system.
16
17 Files shipped with PolicyKit and 3rd party packages (e.g. under package
18 manager control) typically have comments (such as “DO NOT EDIT THIS
19 FILE, it will be overwritten on update”) telling the system
20 administrator that changes will be overwritten on update.
21
23 PolicyKit makes a distinction between user authentication (to make the
24 user in front of the system prove he really is the user) and
25 administrator authentication (to make the user in front of the system
26 prove he really is an administrator). Since various operating systems
27 (or even flavors of the same operating system) has different ways of
28 defining "administrator", the Local Authority provides a way to specify
29 what "administrator authentication" means.
30
31 By default, "administrator authentication" is defined as asking for the
32 root password. Since some systems, for usability reasons, don't have a
33 root password and instead rely on a group of users being member of an
34 administrative group that gives them super-user privileges, the Local
35 Authority can be configured to support this use-case as well.
36
37 Configuration for the Local Authority is read from files in the
38 /etc/polkit-1/localauthority.conf.d directory. All files are read in
39 lexigraphical order (using the C locale) meaning that later files can
40 override earlier ones. The file 50-localauthority.conf contains the
41 settings provided by the OS vendor. Users and 3rd party packages can
42 drop configuration files with a priority higher than 60 to change the
43 defaults. The configuration file format is simple. Each configuration
44 file is a key file (also commonly known as a ini file) with a single
45 group called [Configuration]. Only a single key, AdminIdentities is
46 read. The value of this key is a semi-colon separated list of
47 identities that can be used when administrator authentication is
48 required. Users are specified by prefixing the user name with
49 unix-user: and groups of users are specified by prefixing with
50 unix-group:. See the section called “EXAMPLES” for an example of a
51 configuration file.
52
54 The Local Authority reads files with .pkla extension from all
55 directories located inside the /etc/polkit-1/localauthority and
56 /var/lib/polkit-1/localauthority directories. By default, the following
57 sub-directories are installed.
58
59 /etc/polkit-1/
60 `-- localauthority
61 |-- 10-vendor.d
62 |-- 20-org.d
63 |-- 30-site.d
64 |-- 50-local.d
65 `-- 90-mandatory.d
66
67
68 and
69
70 /var/lib/polkit-1/
71 `-- localauthority
72 |-- 10-vendor.d
73 |-- 20-org.d
74 |-- 30-site.d
75 |-- 50-local.d
76 `-- 90-mandatory.d
77
78
79 The /etc/polkit-1/localauthority hierarchy is inteded for local
80 configuration and the /var/lib/polkit-1/localauthority is intended for
81 3rd party packages.
82
83 Each .pkla file contains one or more authorization entries. If the
84 underlying filesystem supports file monitoring, the Local Authority
85 will reload information whenever .pkla files are added, removed or
86 changed.
87
88 Each directory is intended for a specific audience
89
90 10-vendor.d
91 Intended for use by the OS vendor.
92
93 20-org.d
94 Intended for the organization deploying the OS.
95
96 30-site.d
97 Intended for the site deploying the system.
98
99 50-local.d
100 Intended for local usage.
101
102 90-mandatory.d
103 Intended for the organization deploying the OS.
104
105 and new directories can be added/removed as needed.
106
107 As to regards to the content, each .pkla file is a standard key file
108 and contains key/value pairs in one or more groups with each group
109 representing an authorization entry. A .pkla file MUST be named by
110 using a scheme to ensure that the name is unique, e.g. reverse DNS
111 notation or similar. For example, if the organization is “Acme Corp”
112 needs to modify policy for the product “Frobnicator”, a name like
113 com.acme.frobnicator.pkla would be suitable.
114
116 Each group in a .pkla file must have a name that is unique within the
117 file it belongs to. The following keys are are recognized:
118
119 Identity
120 A semi-colon separated list of globs to match identities. Each glob
121 should start with unix-user: or unix-group: to specify whether to
122 match on a UNIX user name or a UNIX group name.
123
124 Action
125 A semi-colon separated list of globs to match action identifiers.
126
127 ResultActive
128 The result to return for subjects in an active local session that
129 matches one or more of the given identities. Allowed values are
130 similar to what can be used in the defaults section of .policy
131 files used to define actions, e.g. yes, no, auth_self,
132 auth_self_keep, auth_admin and auth_admin_keep.
133
134 ResultInactive
135 Like ResultActive but instead applies to subjects in inactive local
136 sessions.
137
138 ResultAny
139 Like ResultActive but instead applies to any subject.
140
141 ReturnValue
142 A semi-colon separated list of key/value pairs (of the form
143 key=value) that are added to the details of authorization result on
144 positive matches.
145
146 All keys specified above are required except that only at least one of
147 ResultAny, ResultInactive and ResultActive must be present. The
148 ReturnValue key is optional.
149
151 When a Mechanism requests services from the Authority to check if a
152 given Subject is authorized for a given Action, the authorization
153 entries discussed above are consulted using the following algorithm.
154
155 The authorization entries from all .pkla files are ordered using the
156 following rules. First all the basename of all sub-directories (e.g.
157 30-site.d) from both the /etc/polkit-1/localauthority and
158 /var/lib/polkit-1/localauthority directories are enumerated and sorted
159 (using the C locale). If a name exists in both /etc and /var, the one
160 in /etc takes precedence. Then all .pkla files are read in order from
161 this list of sub-directories. For each .pkla file, authorizations from
162 each file are appended in order resulting in an ordered list of
163 authorization entries.
164
165 For example, given the following files
166
167 /var/lib/polkit-1
168 └── localauthority
169 ├── 10-vendor.d
170 │ └── 10-desktop-policy.pkla
171 ├── 20-org.d
172 ├── 30-site.d
173 ├── 50-local.d
174 ├── 55-org.my.company.d
175 │ └── 10-org.my.company.product.pkla
176 └── 90-mandatory.d
177
178 /etc/polkit-1
179 └── localauthority
180 ├── 10-vendor.d
181 │ └── 01-some-changes-from-a-subvendor.pkla
182 ├── 20-org.d
183 ├── 30-site.d
184 ├── 50-local.d
185 ├── 55-org.my.company.d
186 │ └── 10-org.my.company.product.pkla
187 └── 90-mandatory.d
188
189
190 the evaluation order of the .pkla files is:
191
192 1. 10-desktop-policy.pkla
193
194 2. 01-some-changes-from-a-subvendor.pkla
195
196 3. 10-org.my.company.product.pkla (the /var one)
197
198 4. 10-org.my.company.product.pkla (the /etc one)
199
200 When the list of authorization entries has been calculated, the
201 authorization check can be made. First, the user of the Subject is
202 determined and the groups that the user belongs are looked up. For each
203 group identity, the authorization entries are consulted in order. If
204 the authorization check matches the data from the authorization check,
205 then the authorization result from RequireAny, RequireInactive or
206 RequireActive is used and ReturnValue is added to the authorization
207 result.
208
209 Finally, the authorization entries are consulted using the user
210 identity in the same manner.
211
212 Note that processing continues even after a match. This allows for
213 socalled “negative authorizations”, see the section called “EXAMPLES”
214 for further discussion.
215
217 The following .conf file
218
219 [Configuration]
220 AdminIdentities=unix-group:desktop_admin_r
221
222
223 that any user in the desktop_admin_r UNIX group can be used for
224 authentication when administrator authentication is needed. This file
225 would typically be installed in the /etc/polkit-1/localauthority.conf.d
226 directory and given the name 60-desktop-policy.conf to ensure that it
227 is evaluted after the 50-localauthority.conf file shipped with
228 PolicyKit. If the local administrator wants to override this (suppose
229 60-desktop-policy.conf was shipped as part of the OS) he can simply
230 create a file 99-my-admin-configuration.conf with the following content
231
232 [Configuration]
233 AdminIdentities=unix-user:lisa;unix-user:marge
234
235
236 to specify that only the users lisa and marge can authenticate when
237 administrator authentication is needed.
238
239 The following .pkla file grants authorization to all users in the staff
240 group for actions matching the glob com.example.awesomeproduct.*
241 provided they are in an active session on the local console:
242
243 [Normal Staff Permissions]
244 Identity=unix-group:staff
245 Action=com.example.awesomeproduct.*
246 ResultAny=no
247 ResultInactive=no
248 ResultActive=yes
249
250
251 If the users homer and grimes are member of the staff group but policy
252 requires that an administrator needs to authenticate every time
253 authorization for any action matching com.example.awesomeproduct.* is
254 required, one would add
255
256 [Exclude Some Problematic Users]
257 Identity=unix-user:homer;unix-user:grimes
258 Action=com.example.awesomeproduct.*
259 ResultAny=no
260 ResultInactive=no
261 ResultActive=auth_admin
262
263
264 and make sure this authorization entry is after the first one.
265
267 Written by David Zeuthen davidz@redhat.com with a lot of help from many
268 others.
269
271 Please send bug reports to either the distribution or the polkit-devel
272 mailing list, see the link
273 http://lists.freedesktop.org/mailman/listinfo/polkit-devel on how to
274 subscribe.
275
277 polkit(8)
278
279
280
281polkit May 2009 PKLOCALAUTHORITY(8)