GNOME Bugzilla – Bug 531406
GConf can't work when account home directory is not writable
Last modified: 2018-08-17 13:55:00 UTC
Please describe the problem: When home directory is not writable, GConf can't work because of "~/.gconf" and "~/.gconfd". AFAIK, user home directory is probably unwritable in some cases, for example. - System installation. At this time, real filesystem probably isn't created on disk and install image is just loaded from CDROM or RAM. Home directory isn't writable. - Running login-screen of GNOME display manager. On Solaris, to ensure security by default, login-screen is run in a locked account, which of home directory isn't writable. It is possible to move ".gconf" and ".gconfd" under system temporary directory "/tmp", or not require ".gconf" if home dir isn't writable? Steps to reproduce: 1. Use GConf infrastructure in the case of home directory is not writable. Actual results: Display error "Unable to open saved state file '/.gconfd/saved_state': Permission denied" Expected results: gconfd and gconf APIs can work correctly. Does this happen every time? Yes. Other information:
Created attachment 110361 [details] [review] patch for gconfd daemon Once home dir isn't writable, use system temporary directory instead.
Hi GConf maintainers, could you have a look at this issue? It's still reproducible on gconf 2.23. On Solaris, GDM is run as user "gdm", who is a locked account and doesn't have a writeable HOME directory. So this gconf issue results in new GDM (version 2.23) can't work on Solaris.
What happens if you have two users with non-writable home directories? Is this even worth supporting? I think gdm should be given a writable home directory. It doesn't increase security it just breaks gdm.
This is not a GDM specific issue. Though it would obviously be nicest if GDM didn't stumble over itself when a user is missing. Being able to run GConf (or GNOME in general) with no writable $HOME directory is useful in many situations. LiveCD or read-only boot images should work reasonably without having to do complicated things just to ensure that certain $HOME directories exist and are writable. Being able to support programs working when the user's $HOME directory is read-only just ensures that GNOME works properly in this situation. It would suck, for example, if all my programs stopped working if I accidently ran chmod on my $HOME directory. A temporary directory in /tmp seems easy enough. If you have two users with non-writable $HOME directories, then why not include the unique username in the temporary directory name used? Or why not just default back to all mandatory settings in this case? This would cause some programs that need to save state to break, but would allow many programs to work as normal.
The Correct Solution would be to have no writable gconf sources and then apps are supposed to handle that by disabling their settings. Of course it isn't practical to fix all the apps. I don't think the desktop works in general with non-writable homedir, gconf or not. So I'm not sure livecd applies. Realistically the way to deal with a livecd is to have a ramdisk or usb homedir, I'm pretty sure that's what they all do. storing settings in /tmp I think is basically crack. If you're going to throw the settings out and make gconf a no-op, create a /dev/null backend or something, or make a ramdisk homedir, or I don't know. Or just set HOME to /tmp/throwaway-XXXXX and fix everything at once not just gconf.
At any rate, it seems that GConf should have some mechanism to behave sensibly when there is no writable $HOME directory. Falling back to any default settings and failing to save any state seems reasonable behavior in this situation. If GConf could be run in this way, then it would be GDM's bother to figure out when this situation has happened and what to do about it. Would it be a reasonable solution for GConf to allow the calling program to specify the location of the user's configuration directory? Currently GConf just hard-codes that these directories must exist in the user's $HOME directory. So, the calling program doesn't really have the ability to redirect this sensibly (or as needed) when it detects the non-existence of a writable $HOME directory. Since GConf runs as a daemon, if gnome-session started it with an environment variable set to specify that GConf user configuration be stored in a ramdisk for example, then GNOME could easily be made to just work well regardless of whether the user's $HOME directory is writable or not. This sort of feature might just make it easier to produce LiveCD's since this feature could be made to work out-of-the-box?
GConf has been deprecated since 2011. GConf is not under active development anymore. Its codebase has been archived: https://gitlab.gnome.org/Archive/gconf/commits/master dconf and gsettings are its successors. See https://developer.gnome.org/gio/stable/ch34.html and https://developer.gnome.org/GSettings/ for porting info. Closing this report as WONTFIX as part of Bugzilla Housekeeping to reflect reality. Feel free to open a task in GNOME Gitlab if the issue described in this task still applies to a recent + supported version of dconf/gsettings. Thanks!