Local Authority plan

Dario Freddi drf54321 at gmail.com
Fri Jun 26 01:26:51 PDT 2009

Hey David,

I won't answer in blocks since your mail was pretty long and clear. First 
things first, what you described seems great. Although, I have a couple of 

Basically, your structure of preferences is the following


However, I believe 10 and 20 should be inverted. I mean, in my vision we have 
the following situation

 -  Developer A develops a Polkit based application, and defines some default 
 - Distribution B believes that policies set by A are not really fitting their 
way of doing things, so it puts its own pkla in the upper level
 - The user, again, overrides it

If that's what you meant, I misunderstood you.

Then, for groups and stuff, it would be really nice to integrate this is the 
polkit-authorization manager. I mean, at the moment you can define Everyone-
Active Console, etc. It would be nice if one could set the group permission as 
well. Also, you didn't talk/I didn't see anything related to ConsoleKit.

Having a distinction between the Active/Inactive console is quite fundamental 
in my opinion: how will you take care of this matter with .pkla? Also, are 
.policy files going to disappear in favor of .pkla?

On Friday 26 June 2009 00:29:13 David Zeuthen wrote:
> Hey,
> 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
>       similar)
>     - 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
>     and site
>     - we want a D-Bus API for doing this
>       - Object:    /org/freedesktop/PolicyKit1/LocalAuthority
>         Interface: 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
>  /var/lib/polkit-1/localauthority/10-osvendor.d/
>                                   20-org.d/
>                                   30-site.d/
>                                   99-local.d/
> Files in each directory
>  - MUST have the .pkla suffix
>  - SHOULD use a unique name using reverse DNS style, e.g.
>     org.fedoraproject.fedora.desktop-spin.pkla
> and may contain zero or more entries like this
>  Version=1
>  Identity=unix-group:desktop-user;unix-group:desktop-admin
>  Action=org.freedesktop.devkit-disks.drive-ata-smart*
>  Result=yes
> where
>  [ATA SMART]  :  Name of the authorization; must be unique for
>                  the file
>  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
>                  multiple identities
>  Action       :  A glob (cf. glob(3)) for matching actions
>  Result       :  What to return, see [1]
> 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
>  [Deny All]
>  Version=1
>  Identity=unix-user:*
>  Action=*
>  Result=no
> that denies everything. Or
>  [Paranoid]
>  Version=1
>  Identity=unix-user:*
>  Action=*
>  Result=auth_admin
> 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
>  polkit-desktop-policy.noarch.rpm
>  polkit-kiosk-policy.noarch.rpm
>  polkit-server-policy.noarch.rpm
>  polkit-denyall-policy.noarch.rpm
> 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
>     pk-desktop-user
>     pk-desktop-power-user
> where
>  - 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
> described here
> https://www.redhat.com/archives/fedora-desktop-list/2008-May/msg00006.html
> 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.
>      David
> [1] : Description of Result in .pkla files is basically what we already
> put in .policy files. See
>  http://hal.freedesktop.org/docs/polkit/PolicyKit-1.8.html
> for the possible values. E.g. "no", "yes", "auth_self", "auth_admin",
> "auth_self_keep", "auth_admin_keep".
> _______________________________________________
> polkit-devel mailing list
> polkit-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/polkit-devel


Dario Freddi
KDE Developer
GPG Key Signature: 511A9A3B
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
Url : http://lists.freedesktop.org/archives/polkit-devel/attachments/20090626/a51073bf/attachment.pgp 

More information about the polkit-devel mailing list