Local Authority plan
david at fubar.dk
Thu Jun 25 15:29:13 PDT 2009
The last item for polkit for 1.0 is to provide a way to control
authorizations on a per-user and per-group basis when using the Local
Authority (called LA in the following).
First, what does this mean? It means being able to grant authorizations
to for an Action A and Identity I (such as a user U or a group G) such
that if a Subject S (e.g. a process running on your system with pid P or
D-Bus unique system bus name D) is owned by I and a Mechanism M is
asking whether S is authorized for A, then we know what to answer by
looking up files on the local filesystem (rather than defaulting to the
defaults in the .policy file like we do know).
(yes, that was terse, hopefully it will get easier to understand later
in this mail)
Second, let us look at the requirements for such a solution.
o OS vendors ship many different kind of products, we need it to be
very easy to configure the LA; examples
- need to configure all current and future actions to request admin
authentication when needed (this makes sense on a "hardened"
and "secure" system) - this probably means we need to use some
kind of globbing or regexp
- need a way for the OS vendor to ship the policy in files
that are installed via RPMs (or similar) with relying on fragile
%post snippets (or similar) being run on the target machine. In
particular, can't rely on having the polkitd-1 daemon around at
%post time (might run in a chroot for livecd creation etc.)
- need a way to the organization owning the machine (e.g. a company
deploying PolicyKit to ship policy files; these files override
what the OS vendor provides. Again, installed via RPMs (or
- need a way to the site running the machine (e.g. a department
in the company deploying PolicyKit) to ship policy files; these
files override OS vendor and site-provided files. Again, installed
via RPMs (or similar)
o Should be possible to configure authorizations for the local
machine; this overrides what is provided by the OS vendor, org
- we want a D-Bus API for doing this
- Object: /org/freedesktop/PolicyKit1/LocalAuthority
- (this replaces the existing AuthorityManager stuff in git master)
- We want a command line tool, pklamanage, that uses the D-Bus API
- In GNOME, we want a GTK+ based tool that uses the D-Bus API
- configuring authorizations will in turn require authorization; we
can conveniently use PolicyKit itself for this (and OS vendors,
orgs and sites can thus completely lock this down)
o Authorization files provided by RPMs (or similar) should never be
changed by doing local changes. So we need some kind of stacking
like GConf has.
o Need more than just the ability to "grant" an authorization; e.g.
we want to be able to do things like
- for action, org.foo.xyz, always require admin auth (even if
the defaults in the policy is "yes")
- have negative authorizations - for example, if user U is member
of the group G and everyone in G is authorized for the action
org.foo.xyz, make it possible to say that U is not
The proposed solution is this. Files with authorization information will
be stored in ini-key like files (e.g. files parseable by GKeyFile). We
will use the following directory hierarchy
Files in each directory
- MUST have the .pkla suffix
- SHOULD use a unique name using reverse DNS style, e.g.
and may contain zero or more entries like this
[ATA SMART] : Name of the authorization; must be unique for
Version : The version of the authorization format (so we can make
incompatible changes later on without breaking stuff)
Identity : A semicolon separated list of identities for which the
authorization applies. Globs can be used to match
Action : A glob (cf. glob(3)) for matching actions
Result : What to return, see 
The snippet above basically says that any user in the UNIX group
'desktop-user' and 'desktop-admin' is authorized for any action that
matches the org.freedesktop.devkit-disks.drive-ata-smart* glob.
Another example is this
that denies everything. Or
that requires admin authentication for everything.
The plan I have in mind for Fedora (and GNOME) is that we will be
providing a number of RPMs such as
all providing polkit-policy so you can only have one of them installed
at the same time. Each RPM will contain authorization configuration that
matches the usage scenario.
Specifically for the polkit-desktop-policy we want to configure things
in a way so the authentication prompts are very rarely shown. This
includes introducing a couple of UNIX groups
- pk-desktop-guest: a very restricted account; we lock down all
actions here and punch a few holes
- pk-desktop-user: full access to change timezone / manage most
hardware; install trusted software
- pk-desktop-power-user: install software / add/remove users
Managing things this way allows you to very easily integrate this into
the user account editor effort (which is stalled at the moment, grr) as
E.g. the basic idea is that we can have a very simple User Interface
that adds/removes capabilities to a certain user account.
Also, as the OS evolves and new PolicyKit actions are added, we simply
just update the polkit-desktop-policy.noarch.rpm to include the new
actions. For example, if, say, someone adds a new framework to control
the firewall in F12 or F13, we can grant the needed authorizations to
the pk-desktop-* groups in order to make them use their system without
having to endure useless authentication dialogs.
Any feedback more than welcome. I will start working on this in a couple
of days. I will send more updates to the list as I progress.
 : Description of Result in .pkla files is basically what we already
put in .policy files. See
for the possible values. E.g. "no", "yes", "auth_self", "auth_admin",
More information about the polkit-devel