Re: Major problem with gconf mandatory settings.

[Joerg Barfurth <jub sun com>]

Hi Marcin,

Marcin Antczak wrote:
> Recently I was learning about gconf and found information about 
> mandatory settings.
>
> This is very important GConf feature - very usable for administrators 
> etc. But this implies a major bug in almost all gnome applications with 
> gconf support.

I don't think it is quite as bad. But it is true that applications need 
to be aware of this possibility to create the proper user experience.

> My english is poor so simple CLI example:
>
> gconftool-2 --direct --config-source 
> xml:readwrite:/etc/gconf/gconf.xml.mandatory/ --type string --set 
> /desktop/gnome/background/picture_filename /home/marcin/ncube-1600.jpg
>
> And now every user has wallpaper set to /home/marcin/ncube-1600.jpg - 
> just because root wants to.
>
> This is nice but then user can run application called 
> gnome-background-properties and can try to change wallpaper.

In this case gnome-background-properties should notice that the setting 
is locked and disable the change. At the very least it should report an 
error when saving the change to gconf fails.

> But wallpaper will not change because user settings are overriden with 
> mandatory settings - while user _will not have an idea about this_.
> And propably will think that gnome-background-properties is just broken.

If gnome-background-properties neither reflects the lockdown in advance 
nor reports that the change failed because the setting is locked down, 
then it *is* broken.

> The problem is that this scenario can be applied in any application - 
> for example in eog we can in mandatory settings turn off toolbar - and 
> user can try to turn on toolbar in "view" menu to the end of time...

Again, this is the responsibility of the application. The preferred way 
of supporting this is to disable the control, the fallback is to report 
the failure.

> In my opinion this is a serious "structural" bug in gnome preferences 
> system.

If this problem is as wide-spread as you think (I am afraid you are 
probably right), then it is a 'structural' bug in gnome application 
programming. It is probably caused by the fact that the feature hasn't 
been that widely used and that hackers rarely work in locked down 
environments.

But it is not a bug in the preference system. There are similar 
potential issues with e.g. files. If an application does not care 
whether a file is write-protected and doesn't report an error if saving 
data fails because of missing permissions, then it isn't the file system 
that is broken.

> And I'am writing about this here because I don't know where exactly 
> report this as a bug - gconf bug? Or maybe prepare a hundred of bug 
> reports for each application that uses gconf?

It really is the latter. An this is work in progress. We've been trying 
to report or fix such bugs when we encounter them.

BTW: This isn't restricted to gconf and gnome applications. There are 
similar lockdown mechanisms in the mozilla and OpenOffice.org 
configuration systems - and there are similar problems when that is 
actually used.

> I think that this has to be resolved - and I suppose that solution 
> should be "centralized" - some kind of notification system, but I'm not 
> C developer only system administrator and user.
> And I'm asking for an advise - what do you think what to do with this?

I'm afraid there really isn't a way to centralize the solution.

Ciao, Joerg

--
Joerg Barfurth              Sun Microsystems - Desktop - Hamburg
>>>>>>>>>>>>>>>>>> using std::disclaimer <<<<<<<<<<<<<<<<<<<<<<<
Software Engineer                         joerg barfurth sun com
OpenOffice.org Configuration          http://util.openoffice.org