g_get_home_dir (), ${HOME}, and getpwuid ()->pw_dir

[Ivan Shmakov <oneingray gmail com>]

	[This issue is currently being discussed in debian-devel@ [0],
	and it was suggested to bring it to gtk-devel-list@ as well.]

    Abstract

	It's suggested that g_get_home_dir () be changed to follow the
	usual Unix convention of using ${HOME} as the user's home
	directory, falling back to getpwuid ()->pw_dir should HOME be
	non-existent or empty, or, additionally, should it point to a
	directory not owned by the current user, or on which he or she
	has no executable permission, unless the current user is ‘root’
	(UID 0.)


    Status quo

	The g_get_home_dir () description reads [1]:

--cut--
    Gets the current user's home directory as defined in the password
    database.

    Note that in contrast to traditional UNIX tools, this function
    prefers passwd entries over the HOME environment variable.
--cut--

	The environment is the preferred place to check for this kind of
	things, as it's (usually) under the full control of the user,
	and it's quite possible to run several instances of a single
	program using different environments, which may be useful for a
	variety of purposes, such as:

	• testing and debugging; for instance, one may (normally) switch
	  to the all-defaults configuration for ‘foo’ like:

$ HOME="$(mktemp -dt -- home.XXXX)" foo 

	  or one may use a configuration file attached to a bug report
	  without ever needing to move his or her own one, etc.;

	• using a networked FS (NFS, AFS, CIFS, etc.) home directory
	  instead of the passwd(5)-configured local one, or vice versa;

	• running build-time tests, in an effectively “homeless”
	  environment.

	It should also be noted that allowing user to override the
	system configuration (which getpwuid () is a part of) with the
	use of environment variables or command-line arguments is a
	well-established Unix convention.  For instance, it's generally
	possible to override user's home directory (HOME), local time
	zone (TZ), locale (LANG, LC_*), various search paths (PATH for
	executable files, MANPATH for manual page files, LD_LIBRARY_PATH
	for shared libraries on GNU/Linux), etc.

	The documentation [1] also states:

--cut--
    […]  If applications want to pay attention to HOME, they can do:

    1  const char *homedir = g_getenv ("HOME");
    2  if (! homedir)
    3    homedir = g_get_home_dir ();
--cut--

	Unfortunately, only a minority of software seem to implement the
	above (e. g., [2] does.)  On the other hand, there's a number of
	bug reports asking for the behavior to be changed to match the
	usual Unix conventions (e. g., [3, 4].)  Also, as a work-around
	for running self-tests under the Debian build environment, the
	Debian ‘glib2.0’ package implements the support for the
	Debian-specific ‘G_HOME’ environment variable, which takes
	precedence over getpwuid ()->pw_dir [5]:

--cut--
glib2.0 (2.18.4-1) experimental; urgency=low

  [ Josselin Mouette ]
  * 04_homedir_env.patch: new patch.  Handle the G_HOME environment
    variable, to override the passwd entry.  This will allow to fix
    various kinds of build failures due to restricted build
    environments.

  [ Sebastian Dröge ]
  * New upstream bugfix release.

 -- Sebastian Dröge <slomo debian org>  Sat, 10 Jan 2009 14:21:55 +0100
--cut--

	However, implementing such work-arounds in all the software that
	uses Glib doesn't seem like a reasonable solution.


    The proposal

	The rationale behind the currently implemented behavior is as
	follows [1]:

--cut--
    One of the reasons for this decision is that applications in many
    cases need special handling to deal with the case where HOME is

    Not owned by the user
    Not writeable
    Not even readable

    Since applications are in general not written to deal with these
    situations it was considered better to make g_get_home_dir () not
    pay attention to HOME and to return the real home directory for the
    user.  […]
--cut--

	There's a further clarification at [6] that the use of su(8) and
	sudo(8) may leave HOME pointing to a directory inaccessible by
	the current user.

	To address these concerns, I'd like to suggest that, along with
	changing the behavior to follow the Unix convention (as
	described above), Glib should disregard the value of the HOME
	environment variable, should it (being existent and non-empty)
	point to a directory not owned by the current user, or on which
	he or she has no executable permission, unless the current user
	is ‘root’ (UID 0.)

	Additionally, the directory pointed to by ${HOME} may be
	disregarded should it point to a directory not writable or not
	readable by the current user, though it doesn't seem necessary,
	as the software relying on g_get_home_dir () often stores its
	files under a subdirectory of the home directory returned, which
	may be accessible even if the home directory is not (and vice
	versa.)  Obviously, the current g_get_home_dir () behavior is
	not a safeguard against it.

	The exclusion of the ‘root’ (UID 0) user from the common logic
	is justified as (unless a networked FS, or a similar setup, is
	used) such user's access is generally not restricted by the file
	ownership.  Additionally, the majority of the software is not
	really intended to be run under the ‘root’ privileges, and such
	a use is generally discouraged anyway.


    References

[0] http://comments.gmane.org/gmane.linux.debian.devel.general/176973
[1] http://developer.gnome.org/glib/2.28/glib-Miscellaneous-Utility-Functions.html
[2] http://zathura.pwmt.org/projects/girara/doxygen/utils_8c_source.html
[3] http://bugs.debian.org/453711
[4] http://bugs.irssi.org/index.php?do=details&task_id=532
[5] http://packages.debian.org/changelogs/pool/main/g/glib2.0/glib2.0_2.33.12+really2.32.4-1/changelog
[6] https://bugzilla.gnome.org/show_bug.cgi?id=2311

-- 
FSF associate member #7257