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

[Ivan Shmakov <oneingray gmail com>]

>>>>> Matthias Clasen <matthias clasen gmail com> writes:

	FWIW, I've filed Debian Bug#688932 [1] to track this issue in
	the Debian GLib package.

[1] http://bugs.debian.org/688932

[…]

 > The actual commit is

 > Tue Mar  5 00:38:54 2002  Owen Taylor  <otaylor redhat com>

 > * glib/gutils.c (g_get_any_init): Where we have getpwuid[_r], use
 >   that in preference to $HOME, and only check $HOME as a fallback if
 >   getpwuid fails.  (#2311)

 > And the detailed analysis leading to this change is in

 > http://mail.gnome.org/archives/gtk-devel-list/2002-March/msg00066.html

	ACK, thanks for the pointer.

 > I don't think anything has changed there, really.

	Unfortunately, this analysis only concerns the change to the
	HOME environment variable (or lack thereof) made by sudo(8),
	su(8), and usermode.  The question of user changing this
	variable manually wasn't considered there.

	The point is that the software is generally made so that the
	system's configuration (/etc) can be overridden by user's
	(HOME), which, in turn, can be overridden by environment
	variables (FOO_WHATEVER) and, finally, command line arguments
	(--whatever=) or interactively (Edit → Preferences → Whatever.)
	This is a reasonable behavior, and though GLib deviates from it
	also for a reason, it really harms the operation of the
	GLib-based software.

	For instance, there's an easy way to let GNU Emacs read
	/net/home/jrh/.emacs (on NFS) upon initialization, instead of
	/home/jrh/.emacs (on local FS), like:

$ HOME=/net/home/jrh emacs 

	Moreover, GNU Bash started under such a Emacs instance will also
	use /net/home/jrh/.bashrc (instead of /home/jrh/.bashrc), and so
	will GNU Wget, or Lynx, and a sheer variety of other tools.

	… But not the bulk of GNOME, which will insist on using
	/home/jrh/.whatever, perhaps leaving the user no way to choose
	otherwise (sans of persuading the local passwd(5) — or the
	site's LDAP — administrator to change his or her account.)

	The other use case is that the user can always temporarily
	revert to the defaults by using a deliberately empty HOME (say,
	while troubleshooting), like:

$ mkdir -- /tmp/empty 
$ HOME=/tmp/empty myapp 

	Likewise, this isn't going to work for the majority of the GNOME
	applications.

	With the proposed change, these applications will behave just as
	the users expect them to.  Furthermore, I believe that the
	concerns raised in 2002-March/msg00066.html would be relieved,
	provided that the ownership of the directory HOME points to be
	checked as suggested.

 > And it is far too late to change the behaviour of this function, a
 > decade later.

	Then, we're still having a whole lot of GLib-based applications
	to file bug against (as it was just suggested in [2]; and where
	such a bug wasn't filed already), which are then to be fixed in
	each of these applications separately.  Is it really the better
	road to go?

	TIA.

[2] news:20120927124400 GA13234 server brlink eu
    http://permalink.gmane.org/gmane.linux.debian.devel.general/176994

-- 
FSF associate member #7257