Re: GNOME privilege library

[Rob Taylor <robtaylor fastmail fm>]

Sean Middleditch wrote:

> GNOME needs a way to handle a general problem (that has many use cases)
> and can handle it using different implementations for different base
> operating systems.
>  
<snip: lots of good ideas>

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, the unprivileged 
client, the privileged service providing backend, 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 get 
the uid of the process that initiated the dbus 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 error. 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 forms 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). 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 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