Re: GLF- Gnome Lockdown Framework

[Alexander Larsson <alexl redhat com>]

On Tue, 2004-03-02 at 20:43, arch enterprise hb se wrote:
> Citerar Mark McLoughlin <mark skynet ie>:
> 
> >   + Any setting/preference can be locked down - so why define another 
> >     framework on top of GConf specifically for settings which we feel
> >     are "lockdown" settings?
> 
> First of all, GLF is not "on top of" GConf - it is just a standard namespace
> definition in GConf. And why? Because of purely technical reasons. Let's use an
> example.
> 
> Let's say we want to enable lockdown features in app 'foo' (module name fooapp).
> This app goes normally under /apps/fooapp in GConf. Now, how would you store
> and look up the permissions for fooapp, knowing there are separate user-, group-
> and default permissions?
> 
> Let's say this was not standardized, so we decide to store the information in
> the root of /apps/fooap, like this:
> 
> ./users/$username/canDoFoo (bool)
> ./groupwise/$groupname/canDoFoo (bool)
> ./notassigned/canDoFoo (bool)
>
> There is no API available, so you'd have to write the code that checks for
> default, group and user permissions yourself (ad hoc).
> 
> Now, let's say developer B has created a nifty little program as well, calling
> it 'barapp'. He realizes that lockdown functionality would be useful for his app as
> well, so he also creates some arbitrary keys in GConf (under
> /apps/barapp/locking, to separate lockdown keys from others as, say,
> /apps/barapp/appearance):
> 
> ./canDoFooUsers (list of users that are given the foo permission)
> ./canDoFooGroups (list of groups that are given the foo permission)
> ./defaultCanDoFoo (bool)
> 
> Now again, there is no API available, and as he thinks that named lists is a
> better way of representing user and group permissions, he has to write the code
> himself (not being able to re-use much of the code from fooapp).
> 
> Lastly, let's think of the administrator:
> - In case A (fooapp), he has to set boolean values in some subdir of
> /apps/fooapp, depending on who he wants to lockdown.
> - In case B (barapp), he has to change the string values of a list type in the
> root dir of /apps/barapp, if he wants to lockdown somebody.
> 
> Administering a machine with both fooapp and barapp installed will thus require
> special knowledge of the respective ways to lockdown these applications - and in
> this example, I'm only talking of TWO applications (in reality, there will
> probably be many more). No consistency, no machine-readable representation.
> 
> Ok, so after a while the authors of fooapp and barapp realize from reading
> sysadmin posts on the net that administrating policies in GNOME is a mess,
> and they decide to make life easier for the poor sysadmins: they go together to
> write a tool where a sysadmin can choose a user or a group from a list, click
> 'next', select either fooapp or barapp, click 'next', and then the individual
> feature keys that the current (stable) versions of fooapp and barapp use (in
> their usual ho-hum-hack-away-method). Voilá. The sysadmins around the world now
> have a nifty little tool ('foobar-policy-tool') for administrating fooapp and
> barapp. And all is good, until the amazing bazapp (indispensable for every true
> GNOME desktop) comes around...
> 
> Now, 'foobar-policy-tool' is immediately outdated, and needs to be reworked.
> Authors of fooapp and bazapp disagree over bazapp's inclusion in
> foobar-policy-tool, so the authors of bazapp and barapp write a separate tool
> for handling barapp and bazapp. Sysadmins around the world now have two separate
> tools (of which distribution A, B and D only choose to include the the newly
> written barbaz-policy-tool for some reason, resulting in sysadmins with fooapp
> installed have to go back to editing the keys for fooapp manually in gconf,
> again starting to grumble in public of the un-usability and un-consistency of
> free software, resulting in yet more "is Linux ready for the desktop"
> discussions on OSNews and ZDNet)
> 
> Do I make myself clear?
> 
> P.S.  GLF is not on top of GConf  D.S.

All of this discussion *is* "on top of GConf". GConf already has a
concept of different sources for defaults and writability. Although it
does need some slight extensions to be easily usable, see the groups
idea in the mail you linked to above.

There should never be any need for an app to do anything else than look
at the /apps/$app/lockdown/allow_foo key(or whatever key is used) . The
mapping of this value to the right value depending on the user/groups
etc should be automatically handled by the gconf backend. Anything else
is broken.

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 Alexander Larsson                                            Red Hat, Inc 
                   alexl redhat com    alla lysator liu se 
He's a benighted coffee-fuelled barbarian with a mysterious suitcase 
handcuffed to his arm. She's a tortured red-headed mercenary from a family of 
eight older brothers. They fight crime!