GNOME Bugzilla – Bug 530975
g-s-d should work if user has no writable $HOME directory
Last modified: 2008-11-03 19:15:07 UTC
Currently g-s-d will not start up if the user does not have a writable $HOME directory. Now that GDM depends on g-s-d, this causes a problem if the "gdm" user is defined to not have a writable $HOME directory. It seems g-s-d should work reasonably even in this case. I'm attaching a minor patch which simply checks if the user has write permission on their $HOME directory. If not, it sets the GNOME_PARAM_CREATE_DIRECTORIES to false when calling gnome_program_init. This fixes g-s-d so it works even in this case. Can this patch go upstream?
Created attachment 110252 [details] [review] patch fixing problem
What exactly goes wrong when GnomeProgram cannot write to $HOME? What does it want to do?
*** Bug 531566 has been marked as a duplicate of this bug. ***
Jens, some g-s-d plugins are trying to create their configuration file under ".gnome2". See below. font-manager - ".gnome2/share/fonts" and ".gnome2/share/cursor-fonts" sound-properties - ".gnome2/sound/events/*.soundlist*", xrdb-manager - ".gnome2/xrdb" If .gnome2 doesn't exist, font-manager will pop up a warning dialog. Not sure if these configurations is really needed. Could you have some ways to avoid writable home dir? Or provide a easy interface to override home dir when starting up g-s-d? Environment variable "GNOME22_HOME_DIR" might be a workaround.
If you look at libgnome/gnome-init.c, in the function libgnome_userdir_setup, you will see that, by deafult, libgnome will "exit (1)" if it cannot create user directories such as $HOME/.gnome2. If you set the GNOME_PARAM_CREATE_DIRECTORIES parameter to false, then it will avoid trying to create the directories, and will not exit if it can't create them. So, in short, if you don't pass GNOME_PARAM_CREATE_DIRECTORIES=false, and the user does not have a writable $HOME directory, then the g-s-d will just exit.
Thanks, committed. 2008-05-02 Jens Granseuer <jensgr@gmx.net> Patch by: Brian Cameron <brian.cameron@sun.com> * gnome-settings-daemon/main.c: (main): don't die when the user's home directory is read-only (bug #530975) As for the other patch from bug 531566, just masking the problem and faking some writable home is the wrong approach. All the places where files are created should be able to handle such errors gracefully.
Are those other issues actually a problem, or can we consider this fixed?
The fact that font-manager displays a warning dialog is annoying when you intend to use g-s-d with a user who doesn't have a writable $HOME directory. It would be good to make it possible to configure the dialog to not display. Or perhaps it could just avoid displaying the dialog when the user doesn't have a writable $HOME directory.
I don't know whether those directories are actually used by anything. I'm very sure the warnings are bogus on a "normal" system these days. We might be able to get rid of the directories altogether, but I doubt there's any harm in removing the warnings (or at least demoting them to g_warning or the like, though I'd like to know for what kind of system they are correct; they're simply wrong on mine).
Most of the remaining issues here are fixed by my patch for bug 559163. I don't see the xrdb plugin trying to create a file in ~ anymore. Is that still an issue? *** This bug has been marked as a duplicate of 559163 ***