Re: GNOME privilege library
- From: Carlos Garnacho <carlosg gnome org>
- To: Rob Taylor <robtaylor fastmail fm>
- Cc: desktop-devel-list gnome org
- Subject: Re: GNOME privilege library
- Date: Mon, 17 Jan 2005 03:50:04 +0100
I'd like to express my support to this solution, as far as I've talked
with Carlos Perelló and Rob, the architecture is quite well thought, and
would allow a quite fine grained and customizable security model,
instead of letting backends/daemons manage their own.
oh, and it would be quite compatible with the system tools backends
On Fri, 2005-01-14 at 11:04 +0000, Rob Taylor wrote:
> 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
> 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 :)
> Rob Taylor
> desktop-devel-list mailing list
> desktop-devel-list gnome org
] [Thread Prev