Re: GNOME privilege library

[Carlos Garnacho <carlosg gnome org>]

Hi!,

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
plans

	Regards


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
> 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
> 
> _______________________________________________
> desktop-devel-list mailing list
> desktop-devel-list gnome org
> http://mail.gnome.org/mailman/listinfo/desktop-devel-list