Re: g_get_home_dir (), ${HOME}, and getpwuid ()-pw_dir
Debarshi Ray rishi...@lostca.se writes:
Also to note is that non-GNOME (and even non-desktop) GLib-based
applications were seen in the wild. Consider, e. g., the OpenBSD
version of the Netcat command-line networking diagnostic tool (as of
the version currently in Debian stable [4].) And I'm not yet sure
that the developers of these packages will be eager to implement the
support for the aforementioned variables.
Git supports them:
https://github.com/git/git/blob/master/Documentation/RelNotes/1.7.12.txt#L18-23
ACK, thanks for the information.
However, contrary to GLib, Git actually follows the
specification [1] by falling back to ${HOME}/.config should
XDG_CONFIG_HOME be unavailable. It doesn't seem to use
getpwuid () there at all.
--cut: https://raw.github.com/git/git/master/path.c --
void home_config_paths(char **global, char **xdg, char *file)
{
char *xdg_home = getenv(XDG_CONFIG_HOME);
char *home = getenv(HOME);
char *to_free = NULL;
...
if (!xdg_home) {
to_free = mkpathdup(%s/.config, home);
xdg_home = to_free;
}
...
}
--cut: https://raw.github.com/git/git/master/path.c --
[1] http://standards.freedesktop.org/basedir-spec/basedir-spec-0.8.html
--
FSF associate member #7257
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: g_get_home_dir (), ${HOME}, and getpwuid ()-pw_dir
Tristan Van Berkom t...@gnome.org writes: […] So... maybe we dont want to change the behavior of an api that dates 10 years back, but we might want to at least correct g_get_user_config/data_dir() at this point ? Given that even back then it was noted that “login sets $HOME and until you switch users, it will be left unchanged” [1] (though it misses certain valid use cases), I guess changing g_get_home_dir () to prefer HOME is still a safe move. [1] https://mail.gnome.org/archives/gtk-devel-list/2002-March/msg00066.html […] -- FSF associate member #7257 ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: g_get_home_dir (), ${HOME}, and getpwuid ()-pw_dir
Stef Walter st...@gnome.org writes: On 09/27/2012 04:48 PM, Ivan Shmakov wrote: $ 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.) Nah, you can use XDG Base directories to get the bulk of GNOME to use another directory for files, config, settings and so on. [1] ACK, thanks for the pointer! Set $XDG_CONFIG_HOME, $XDG_DATA_HOME and $XDG_CACHE_HOME. These are exposed to GLib based software as g_get_user_data_dir(), g_get_user_cache_dir() and g_get_user_config_dir(). GNOME is actively moving towards using those. [2] (Actually, [3] mentions also the XDG_RUNTIME_DIR variable, though it doesn't specify a particular default value, or state that such a default should be below user's HOME.) Unfortunately, given the current state of affairs, these variables have to be set /in addition/ to HOME, since there seems to be a number of applications developed prior to the introduction of the XDG conventions, which are still in use. And setting four environment variables isn't as convenient as setting just one. FWIW, the default values for those are supposed to be derived from $HOME according to the XDG Basedir spec. So if the spec is to be taken literally it seems like we should be using $HOME instead of g_get_home_dir(). Indeed. Consider, e. g. [3]: --cut-- $XDG_DATA_HOME defines the base directory relative to which user specific data files should be stored. If $XDG_DATA_HOME is either not set or empty, a default equal to $HOME/.local/share should be used. $XDG_CONFIG_HOME defines the base directory relative to which user specific configuration files should be stored. If $XDG_CONFIG_HOME is either not set or empty, a default equal to $HOME/.config should be used. --cut-- And that is the behavior I hope the future versions of GLib will implement. (Aside from the HOME directory ownership check I've suggested before.) TIA. But anyway, there is a way to use environment variables to change where the 'bulk of GNOME' looks for its stuff. And where not, there is active progress in fixing this issue. Also to note is that non-GNOME (and even “non-desktop”) GLib-based applications were seen in the wild. Consider, e. g., the OpenBSD version of the Netcat command-line networking diagnostic tool (as of the version currently in Debian stable [4].) And I'm not yet sure that the developers of these packages will be eager to implement the support for the aforementioned variables. [1] http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html [2] https://live.gnome.org/GnomeGoals/XDGConfigFolders [3] http://standards.freedesktop.org/basedir-spec/basedir-spec-0.8.html [4] http://packages.debian.org/squeeze/netcat-openbsd -- FSF associate member #7257 ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: g_get_home_dir (), ${HOME}, and getpwuid ()-pw_dir
Colin Walters walt...@verbum.org writes: On Thu, 2012-09-27 at 12:42 +0700, Ivan Shmakov wrote: 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. The question to answer is simple: why does GLib do what it does now? […] So... yeah, not very enlightening =/ This kind of thing is a prime example of why I am constantly asking people to rewrite commit messages to say *WHY*, not what. Simon McVittie was courteous to traverse the Git history for us back to the Bug 2311 [6] at the GNOME Bugzilla. (See [7].) […] 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. […] [6] https://bugzilla.gnome.org/show_bug.cgi?id=2311 [7] http://permalink.gmane.org/gmane.linux.debian.devel.general/176977 -- FSF associate member #7257 ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
g_get_home_dir (), ${HOME}, and getpwuid ()-pw_dir
[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.) 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)
3homedir = 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,
