Re: Locking down the gnome desktop

[Havoc Pennington <hp redhat com>]

On Fri, 2003-12-05 at 13:13, Janyne Kizer wrote:
> 
> I've run into quite a few problems with this and I have some questions 
> as a result.  Firstly, I read the admin guide and saw that there is 
> supposed to be a way to set the panels in gconf.  Unfortunately, I could 
> not get it working at all.  Is this implemented in Gnome 2.2 (that comes 
> with RH9)?
> http://www.gnome.org/learn/admin-guide/2.2/gconf-8.html#gconf-14
> 
> When I was unable to get gconf to do the panel settings, I tried the 
> method mentioned here:
> http://mail.gnome.org/archives/gnome-redhat-list/2003-July/msg00011.html. 
>   I had more success with that but it also brought up more questions.
> 

I helped the Red Hat admins get the panel thing going; the admin guide
was slightly wrong. I don't remember exactly what the issue was.
The panel is more complicated than the rest of GNOME in the way it uses
gconf. I'll try to just explain everything in excruciating detail and
maybe we can link to this mail from a FAQ or someone can incorporate
into the docs.

For a given setting, there are two values in the gconf database. 
One is /schemas/foo/bar and one is /foo/bar. The value at
/schemas/foo/bar is a "schema object" with several fields
(documentation, etc.). One of the fields is the default or factory value
of the setting.

/foo/bar has metadata pointing to /schemas/foo/bar. If there's no value
at /foo/bar, then the value comes from the schema object stored at
/schemas/foo/bar.

Does that make sense?

When the user's desktop looks up a value, there's a search path, which
by default is:
 /etc/gconf/gconf.xml.mandatory -> ~/.gconf ->
/etc/gconf/gconf.xml.defaults

The schema objects are installed to /etc/gconf/gconf.xml.defaults,
normally.

So the value lookup has the following steps, stopping as soon as a value
is found:

 - check /foo/bar in system mandatory
 - check /foo/bar in per-user
 - check /foo/bar in system defaults
 - read metadata to obtain the path /schemas/foo/bar for the schema
 - check /schemas/foo/bar in system mandatory for schema object, extract
   default value if found
 - check /schemas/foo/bar in per-user
 - check /schemas/foo/bar in system defaults
 - return that the value is not present

This is relatively straightforward, and almost all settings work this
way with no extra complexity. The way you set up user defaults is:

 - in an RPM package, usually you'd modify the default value in the 
   schema object ("factory default"); this means patching then 
   reinstalling the .schemas files

 - in your kickstart or other admin scripts, usually you'd just set
   /foo/bar to a value in the /etc/gconf/gconf.xml.defaults location
   (or /etc/gconf/gconf.xml.mandatory if you don't want it changed).
   To do this you'd use gconftool as in the GNOME admin guide.

The idea is that in an admin tool, you could have a "revert to factory"
button that would pop you back to the default from the schema object.

One caveat is that GNOME has gradually gotten better about graceful
handling of mandatory settings. It should work in a lot of places in the
CVS version, but gets worse the older your GNOME.

However, the panel is extra special. It has several ways to confuse you,
which I hope I'll get right:

1. There was an original plan to allow "panel profiles," though this was
   never exposed in the UI. So keys are stored in 
   /apps/panel/profiles/<something>/foo where the <something> is 
   variable - it should usually be "default"

2. In older versions, it would name the subdir for a given panel 
   instance (such as top or bottom panel) with some random number
   like 000001, rather than something like bottom_panel

3. The real fun one - /apps/panel/default_setup. When you log in the
   first time and there are no profiles, the panel _copies manually_ the
   contents of /apps/panel/default_setup to a new profile. So the panel 
   has its sort of own layer of weird on top of gconf.

So, I _believe_ you should be able to create a profile in
/etc/gconf/gconf.xml.defaults, under /apps/panel/profiles/, and the
panel would then simply ignore /apps/panel/default_setup.

The admin guide says there's a toplevel_id_list, but I don't see this in
my current setup; if there's no list like this, I'm assuming panels
found in gconf.xml.defaults can't be deleted by the user since they will
always appear in gconf directory listings, I could be wrong.

> When I set the 
> ~/.gconf/apps/panel/profiles/default/objects/myapp/%gconf.xml to root 
> ownership with read-only access for the userid, the userid took 
> ownership of it anyway upon login.  That doesn't seem right.  I mean, 
> what kind of security is that?  I suppose that I could copy this file in 
> each time that the user logs in but that seems like a lot of unnecessary 
> overhead given the fact that the permissions should have been respected 
> in the first place :-(

The user can chown a file if they own its parent directory, IIRC. This
is just how UNIX works. You don't want file permissions, you want to
modify a configuration source in front of ~/.gconf in the search path,
i.e. /etc/gconf/gconf.xml.mandatory.

> In addition, I have noticed that some of the gconf settings don't 
> "stick" when they are set in mandatory.  For example, I set the following:
> 
> gconftool-2 --direct --config-source 
> xml:readwrite:/etc/gconf/gconf.xml.mandatory --type int --set 
> /apps/clock_applet/prefs/hour_format 12
> 
> gconftool-2 --direct --config-source 
> xml:readwrite:/etc/gconf/gconf.xml.mandatory --type bool --set 
> /apps/clock_applet/prefs/show_seconds false
> 
> gconftool-2 --direct --config-source 
> xml:readwrite:/etc/gconf/gconf.xml.mandatory --type bool --set 
> /apps/clock_applet/prefs/show_date true
> 
> gconftool-2 --direct --config-source 
> xml:readwrite:/etc/gconf/gconf.xml.mandatory --type bool --set 
> /apps/clock_applet/prefs/gmt_time false
> 
> gconftool-2 --direct --config-source 
> xml:readwrite:/etc/gconf/gconf.xml.mandatory --type bool --set 
> /apps/clock_applet/prefs/unix_time false
> 
> Yet users can select 24 hour, seconds, gmt, unix and turn the date off. 
>   When they log off and log back in (after stopping gconfd), the 
> settings that the user makes seem to stick.  This concerns me not 
> because of the clock per se but because when the system adminstrator 
> sets something and makes it mandatory, it should be mandatory.

Some prefs dialogs may not disable themselves in the presence of a
mandatory setting (a bug, please file against each app so broken), but I
would expect a restart of the app to revert to the mandatory setting.
i.e. the app can set ~/.gconf via its prefs dialog all day, but next
time the app queries for the value on startup, it should be getting the
value from the start of the search path. That is, mandatory settings
don't block writing to ~/.gconf, they just mean gconf will find another
value first.

I think there may be something else wrong here, you might want to verify
that the setting is present in /etc/gconf/gconf.xml.mandatory and that
/etc/gconf/gconf.xml.mandatory/apps/clock_applet/prefs/%gconf.xml is
readable by the user. Also be sure you have the right things in your
/etc/gconf/2/path and that no ~/.gconf.path exists.

Havoc