I do remember filing a bug or two against packages that refer to
the getent () data to find the user's “home” directory instead
of using the HOME environment variable.
The environment is the preferred place to check for this kind of
things: 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 (with different executable file
search PATH's, locales, time zones, etc.), which occasionally
turns to be an immense aid to debugging. (Want to use the
all-defaults configuration for a program? Just start it like:
$ HOME="$(mktemp -dt -- foo.XXXXXXXX)" foo)
Now, Glib has g_get_home_dir (), whose 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--
I believe that this behavior is buggy. There's even a (yet
unresolved) bug report [2] against Gimp due to this behavior,
and my guess is that there may be quite a few packages more
affected by it.
While I understand some of the concerns regarding the “Unix”
behavior (also at [1]; quoted below), I'd like to note that the
software which both relies on g_get_home_dir () /and/ stores its
files under a subdirectory of the home directory returned (which
is, arguably, a common practice), is also likely to run into
issues should that /subdirectory/ be made non-writable (or
non-readable), and the current g_get_home_dir () behavior is not
a safeguard against it.
Therefore, I'd like to propose for this behavior to be changed
to match the usual Unix conventions. To address the only
concern listed in [1] I deem valid, I'm also asking that the
value of HOME be disregarded, unless it points to a directory,
which is readable, writable, and owned, by the user.
Unless there be objections (or Glib be quickly patched), I'd be
filing a bug report against libglib2.0-0.
TIA.
--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
--cut--
[1]
http://developer.gnome.org/glib/2.28/glib-Miscellaneous-Utility-Functions.html
[2] http://bugs.debian.org/453711
--
FSF associate member #7257
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/861uhowyp3....@gray.siamics.net
