Re: GNOME privilege library


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

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