Re: GNOME privilege library

[Rob Taylor <robtaylor fastmail fm>]

On Thu, 2005-01-13 at 19:45 +0000, Rob Taylor wrote:
<snip: really bad formatting>

Apologies for that terrible formatting. Thats my honeymoon with
Thurnderbird over ;)

Here's the previous post, formatted sanely:
------------

I've been working on ideas for something like this for a little while 
now, and at the last Ubuntu conference,  Carlos Perello Marin and myself
(along with input from Sjourd Simons and Martin Pitt) hashed out a 
method and a basic implementation that we've been calling accessd.

The basic idea goes like this:

There are 3 players in a given privileged operation:
a)  the unprivileged client, 
b)  the privileged service providing backend, 
c)  and an authorization daemon that simply serves 'authorized' or
   'denied' replys to capability requests.

At every entry point to the service providing backend, the service
discovers the uid of the process that initiated the dbus method call 
(using dbus_bus_get_unix_user), and makes a call to accessd to inquire
whether that user is authorized to perform that operation. 

If so, then it does it, if not, returns an dbus error message. 

These services may also want to provide methods for the clients to
inquire as to their ability to perform the services provided by the
backend.

I've not considered the invocation of these backends, as this method 
allows there to be only one backend per system which allows multiple 
clients, and hence these can be started as normal daemons. dbus service 
activation may allow us to do more funky things, but I've not looked 
into it.

This much is already implemented (in python so far, I'm afraid) - you 
can check out the code from the arch repository -
http://sourcecontrol.net/~rtaylor/robtaylor fastmail fm--2004--accessd/
and discussions are had on #accessd on FreeNode.


The big remaining discussion, (apart from people telling me its crack or
not ;) is as to the form that these capabilities should take.

My current thoughts are for a naming scheme based of the dbus names of
the services plus the name of the capability (e.g.
org.freedesktop.libburn.CanBurn), then a gconf schema type scheme to  
bind these per-backend capabilities together into easily administrated 
chunks (e.g. system.CDBurning). I guess some of you have given more
thought to this particular type of problem than I have :)

The current implementation has a pluggable backend system, though only a
CSV config file based backend is currently implemented. I see LDAP,
MySQL and PostGreSQL backends being important.

Apart from this, other work remaining for an initial release is writing 
some c/glib based examples (maybe a c library if that seems necessary), 
and writing some good documentation (which I'm hoping will come out of 
this discussion, if people see this as a sane plan)

I hope that all made sense :)

Thanks,
Rob Taylor