Thursday, 4 July 2013

More about kerberized Home Directories

In my last post on kerberized NFSv4 home directories I complained that the screen saver looks for configuration files in my home directory which is unavailable. The new behaviour of NFS is to just block if the ticket has expired rather than fail. So the screen saver sits there waiting for a ticket before I can enter my password. One suggestion is to automatically renew tickets. I think this removes some of the benefits of kerberized home directories and just delays this inevitable lock out.

We use the gnome desktop environment, gnome-screensaver can be locked down in such a way that it does not read the user's configuration:

gconftool-2 --direct \ --config-source xml:readwrite:/etc/gconf/gconf.xml.mandatory \
--type bool \
--set /apps/gnome-screensaver/idle_activation_enabled true
gconftool-2 --direct \
--config-source xml:readwrite:/etc/gconf/gconf.xml.mandatory \
--type bool \
--set /apps/gnome-screensaver/lock_enabled true
gconftool-2 --direct \
--config-source xml:readwrite:/etc/gconf/gconf.xml.mandatory \
--type string \
--set /apps/gnome-screensaver/mode blank-only
gconftool-2 --direct \
--config-source xml:readwrite:/etc/gconf/gconf.xml.mandatory \
--type int \
--set /apps/gnome-screensaver/idle_delay 10

I also looked into using xscreensaver instead of gnome-screensaver. Initially, it has the same issues as gnome-screensaver: it tries to find its settings in the user's home directory. xscreensaver supports setting a different home directory via the HOME environment variable. However, we would need to use a wrapper that sets the environment for all xscreensaver commands. I then decided to patch xscreensaver to look for its settings in /var/lib/xscreensaver/$USER.

Unfortunately, in both cases, my GTK theme seems to be looking for files in my home directory that do not exist anyway...

Wrappers for xscreensaver and friends might be the way to go after all.