Local Authority plan

[David Zeuthen]

On Fri, 2009-06-26 at 10:26 +0200, Dario Freddi wrote:
> Hey David,

Hey, thanks for looking at this.

> 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 
> questions.
> 
> Basically, your structure of preferences is the following
> 
>  10-osvendor
>  20-org/site
>  99-user
> 
> 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 
> policies
>  - 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.

Actually, the developer of the mechanism defines the defaults in
the .policy file - only osvendors/orgs/sites should ship .pkla files.
The .pkla files can override what is specified in the .policy files. So
the ordered stack used to perform authorizations decisions looks like
this

 - .policy files
 - osvendor .pkla files
 - org .pkla files
 - site .pkla files
 - user specified authorizations

Also, FWIW, there is no guarantee that the Local Authority is used -
someone may use the null authority (shipped with polkit, denies
everything) or an authority that totally ignores what is in the .policy
files. 

We need to make it very clear in the docs this is the way things works -
e.g. Mechanisms MUST NOT interfere with how the Authority is configured.

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

(ConsoleKit is mostly an implementation detail, we just use it as a
mechanism to get more information about the Subject in question, e.g.
whether the session of Subject is local/remote and active/inactive.)

The question of how to provide an UI around this model is kinda hard. We
want at least two different forms of UI

 - pklamanage(1) - a command-line tool to manage this
 - polkit-[gnome|kde]-authorizations - desktop app

My plan is to just write pklamanage(1) and iterate over how the UI
works. When the command-line tools works in a satisfactory way, it's
probably easier to figure out how the UI tools should work. When I have
a better idea, I'm going to post some thoughts about that.


> Having a distinction between the Active/Inactive console is quite fundamental 
> in my opinion: how will you take care of this matter with .pkla? 

Yea, we should probably replace

 Result=<value>

with

 ResultAny=<value>
 ResultInactive=<value>
 ResultActive=<value>

or something. I didn't do this originally because I'm unsure how it will
affect the UI of pklamanage(1) and the UI tools. I guess we will have to
see ;-)

> Also, are 
> .policy files going to disappear in favor of .pkla?

Nope, the .policy file contains information about the nature of the
action being performed - the .pkla files are intended to only specify
what set of subjects are authorized to perform a given action.

So .policy and .pkla files are really orthogonal to each other.

And .pkla files only applies to the Local Authority - the really grand
plan is that OS vendors / sites can provide their own implementation of
the Authority that reads stuff from a centralized source; the way it
works is that if you want to do that, you just provide an implementation
of this abstract base class

http://hal.freedesktop.org/docs/polkit/PolkitBackendAuthority.html

then you put it in a module in $libdir/polkit-1/extensions and register
it with the

 polkit-backend-authority-1

extension point with a suitable priority. See

http://cgit.freedesktop.org/PolicyKit/tree/src/nullbackend

for an example of how this works. In fact, I'm working with the FreeIPA
team here at Red Hat to do just that.

It is important to emphasize that all this work on the Local Authority
is _just_ for the local authority - things will work in very different
ways if another authority is used. E.g. pklamanage(1) and the associated
UI tools will _not_ work with configuring another authority.

FWIW, this is very intentional insofar that we want to give maximum
freedom to people implementing a PolicyKit Authority - for example, for
the FreeIPA case, I imagine that the configuration of the authority is
done through a web-based interface that can scale to hundreds of
thousands of users or maybe authorizations are computed from other data.
This is not something we ever _want_ to handle with the Local Authority.

     David