Re: GNOME privilege library

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 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 :)

Rob Taylor

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]