Re: GLF- Gnome Lockdown Framework

[arch enterprise hb se]

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.



-------------------------------------------------
This mail sent through IMP: http://horde.org/imp/