Manual Reference Pages - POLICYKIT.CONF (5)
PolicyKit.conf - PolicyKit configuration file
configuration file provides a way for system administrators to override policy for mechanisms that use the PolicyKit library to determine whether a caller is allowed to use the mechanism.
Changes to this configuration file are immediately propagated to running processes using the PolicyKit library. If the configuration file is invalid, processes using this library will log this fact to the system logger and the library will only only return
as the answer to processes using it.
tool can be used to verify that the configuration file is valid.
The configuration file is an XML document. It must have the following doctype declaration:
<!DOCTYPE pkconfig PUBLIC
"-//freedesktop//DTD PolicyKit Configuration 1.0//EN"
The following elements may be present in the configuration file:
This is the root element. A single attribute
must be present and must be set to "0.1" at this point. There can only be one
element in the configuration file.
This element is for matching information related to the decision making process and includes values describing both the caller and the action. This element can be embedded in both
elements (hence allowing for nested matching).
There can only be a single attribute in each
element and POSIX Extended Regular Expression syntax are supported in the value part. The following attributes are supported:
This matches on the users login name.
For matching on the given action being queried for, for example
will match on all actions whose action identifier begins with the string "org.foo.".
This element is for used to specify what result the PolicyKit library will return. It can only be embedded in
elements and can embed no elements itself. The
element is typically used deeply inside a number of
elements. A single attribute,
is supported and it can assume the following values:
Access denied, but authentication of the caller as himself will grant access to only that caller.
Access denied, but authentication of the caller as himself will grant access to any caller in the session of the caller belongs to.
Access denied, but authentication of the caller as himself will grant access any caller with the given uid in the future.
Access denied, but authentication of the caller as an administrative user will grant access to only that caller.
Access denied, but authentication of the caller as an administrative user will grant access to any caller in the session of the caller belongs to.
Access denied, but authentication of the caller as an administrative user will grant access any caller with the given uid in the future.
This element is used to specify the meaning of
"authenticate as administrator". It is normally used at the top-level but can also be used deep inside a number of
elements for conditional behavior.
There can only be a single attribute in each
element. POSIX Extended Regular Expression syntax is
supported in the value part, however multiple values to match on can be separated with the bar (|) character. The following attributes are supported:
Administrator authentication means authenticate as the given user(s). If no
element is given, the default is to use
e.g. administrator authentication mean authenticate as the super user.
Administrator authentication means that any user in the groups matching the given value can be used to authenticate. Typically, on a system with the root account disabled one wants to use something like
to e.g. enable all UNIX users in the UNIX group
to be able to authentication whenever administrator authentication is required.
For brevity, the standard XML and DOCTYPE headers as well as the top-level
are omitted in the following configuration file examples. The actions used may also be fictional, use
polkit-action(1), to learn about the actions available on your system.
The users "davidz" and "bateman" are allowed to do any action:
MOUNTING FIXED DRIVES
Suppose the action
is used to determine whether mounting internal hard drives are allowed. Then this configuration file
specifies that user "davidz" is always allowed to do the action, while user "freddy" is never allowed to do the action. Other users will be subject to the defaults results specified in the
file describing the action.
AVOIDING THE ROOT PASSWORD
Suppose the group
contains the users on a system who are allowed to carry out administrative tasks (ie. tasks that would usually require the root password) on a system where the root account is disabled. Then
can be used to specify that users in said group can authenticate using their own password in instances where the system would normally prompt for the root password.
Written by David Zeuthen
with a lot of help from many others.
Please send bug reports to either the distribution or the hal mailing list, see
[blue] http://lists.freedesktop.org/mailman/listinfo/hal. to subscribe.
|PolicyKit ||POLICYKIT&.CONF (5) ||August 2007 |
Visit the GSP FreeBSD Man Page Interface.
Output converted with manServer 1.07.