Re: GNOME privilege library
- From: Rob Taylor <robtaylor fastmail fm>
- To: desktop-devel-list gnome org
- Subject: Re: GNOME privilege library
- Date: Fri, 14 Jan 2005 11:04:41 +0000
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
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
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 :)
] [Thread Prev