GNOME Bugzilla – Bug 161209
gconf error on login if user has whitespace in homedir path
Last modified: 2018-08-17 13:58:26 UTC
Distribution: Debian 3.1 Package: GConf Severity: major Version: GNOME2.8.1 2.8.x Gnome-Distributor: Debian Synopsis: gconf error on login if user has whitespace in homedir path Bugzilla-Product: GConf Bugzilla-Component: XML backend Bugzilla-Version: 2.8.x Description: Description of Problem: Under gnome 2.8, gnome apps cannot find user gconf database for storing keys if username has *spaces* in (e.g. is authenticating via winbind/pam against nt usernames with whitespaces) All users with whitespaces fail to login succesfully. All users without spaces (authenticating via the same means) always successful - no error. There was no error for any user in previous gnome (e.g. gnome 2.6 - all worked very well before gnome upgrade) Steps to reproduce the problem: 1. setup a workstation to authenticate from an nt server that uses whitespace in username 2. test logins work in gnome 2.6 (or earlier), then upgrade to gnome 2.8 3. attempt gnome 2.8 login from (e.g. gdm) Actual Results: Error starting desktop gnome apps such as gnome panel etc. Gconf complains it cannot open database for storage - user does not get acceptable desktop (no panel, menus etc) Expected Results: Successful login No error - there was no problem using gnome 2.6 with usernames with whitespaces How often does this happen? Every time Additional Information: gnome 2.4, 2.6 login works gnome 2.8 can get no login if user has whitespace
To prove this, one can simply put in a test location in /etc/gconf/2/path, replacing $(HOME)/gconf with something like /home/dirwith space/jsmith, and create a corresponding user and homedir.
2.10 have the same issue.
This looks like it was fixed: 2005-10-18 Tor Lillqvist <tml@novell.com> * gconf/gconf-backend.c (invalid_chars[]): Do allow space in configuration source addresses on Windows, as space is common in user names, and thus home directories (i.e., profile folders).
It seems to me that the commit mentioned in comment 3 only removed SPACE from invalid_chars on the Windows operating system. The original report was for Debian though. There has been a report on the gnucash-user mailing list about being unable to save preferences because the user name contained an ampersand (&). Is it really necessary to forbid so many characters?
Easy steps to reproduce: # mkdir "/mnt/home with space" # adduser --home "/mnt/home with space" sample Now, try to login and you will get the error message: The application "gnome-panel" attempted to change an aspect of your configuration that your system administrator or operating system vendor does not allow you to change. Some of the settings you have selected may not take effect, or may not be restored next time you use the application. As you can see, the homedir can have white spaces in linux, too. The update mentioned in comment 3 must be replicated to others operating systems...
*** Bug 640716 has been marked as a duplicate of this bug. ***
It's easy to remove the Windows special casing of this, but I wonder if we hit more problems down the road with this. Has anyone tried GNOME 3 on such a home dir btw? Does this problem hit us in dconf/gsettings too?
The only restriction in both dconf and gsettings seems to be * @key must be a valid key (ie starting with a slash, not containing * '//', and not ending with a slash).
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!