[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 <sl...@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
_______________________________________________
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list
