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 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
Re: g_get_home_dir (), ${HOME}, and getpwuid ()->pw_dir
Em Thu, 2012-09-27 às 12:42 +0700, Ivan Shmakov escreveu: > [This issue is currently being discussed in debian-devel@ [0], > and it was suggested to bring it to gtk-devel-list@ as well.] What's the TL;DR? It's a very long mail, weirdly formatted, and I don't understand what you expect GLib to do vs. what it does now. Cheers ___ 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
On Thu, 2012-09-27 at 13:34 +0200, Bastien Nocera wrote:
> What's the TL;DR?
>
> I don't understand what you expect GLib to do vs. what it does now.
First two sections of the email explain it:
> 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
>
> Status quo
> The g_get_home_dir () description reads [1]:
> 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.
andre
--
mailto:ak...@gmx.net
http://blogs.gnome.org/aklapper
___
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
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? "git annotate" says the comment dates from: commit 5a866843df0d8dc5e5b81fcf2a8a572b6db31521 Author: Matthias Clasen Date: Wed Feb 2 06:07:14 2005 + Move doc comments inline. Which is just moving around the original comment, so let's dig into that: $ git annotate 5a866843df0d8dc5e5b81fcf2a8a572b6db31521^ -- docs/reference/glib/tmpl/misc_utils.sgml Gives us: commit ea01de53feb47d592ba6401051ac85375e9a45a9 Author: Matthias Clasen Date: Thu Sep 9 14:06:20 2004 + Clarify the relation of g_get_home_dir() and $HOME. 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. ___ 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 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
Re: g_get_home_dir (), ${HOME}, and getpwuid ()->pw_dir
On Thu, Sep 27, 2012 at 9:35 AM, Colin Walters wrote: > 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? > > "git annotate" says the comment dates from: > > commit 5a866843df0d8dc5e5b81fcf2a8a572b6db31521 > Author: Matthias Clasen > Date: Wed Feb 2 06:07:14 2005 + > > Move doc comments inline. > > Which is just moving around the original comment, so let's dig into > that: > > $ git annotate 5a866843df0d8dc5e5b81fcf2a8a572b6db31521^ -- > docs/reference/glib/tmpl/misc_utils.sgml > > Gives us: > > commit ea01de53feb47d592ba6401051ac85375e9a45a9 > Author: Matthias Clasen > Date: Thu Sep 9 14:06:20 2004 + > > Clarify the relation of g_get_home_dir() and $HOME. > > 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. That commit was adding documentation. What else would you say there ? The actual commit is Tue Mar 5 00:38:54 2002 Owen Taylor * 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 I don't think anything has changed there, really. And it is far too late to change the behaviour of this function, a decade later. ___ 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
> Matthias Clasen 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 > * 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.ga13...@server.brlink.eu http://permalink.gmane.org/gmane.linux.debian.devel.general/176994 -- 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
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] 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] 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(). 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. Cheers, Stef [1] http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html [2] https://live.gnome.org/GnomeGoals/XDGConfigFolders ___ 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 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
> 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 Happy hacking, Debarshi -- http://i.imgur.com/Z7jjX.jpg pgp5c5l5BOb1f.pgp Description: PGP signature ___ 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
On Fri, Sep 28, 2012 at 1:38 AM, Stef Walter wrote: > 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] > > 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] > > 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(). > > 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. Ok... I've been enjoying this read and, just thought I might point out that... For example in my system which I installed 2 days ago, there is no $XDG_CONFIG_HOME defined by default in my shell. The spec seems to clearly state that if $XDG_CONFIG_HOME is not defined, $HOME/.config/ should be chosen. g_get_user_config_dir() ... probably getting popular in newer apps... docs say: "On UNIX platforms this is determined using the mechanisms described in the XDG Base Directory Specification." However... upon reading the source... it actually falls back to the value of g_get_home_dir() and not the $HOME which was prescribed by the spec. So, whether glib apps today try to comply with the XDG spec or whether they store things directly in g_get_home_dir()... for the grand majority of systems, they are instead... still getting the password dir instead of the correct directory. Interesting... 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 ? Or, is it a bug in the documentation for g_get_user_*_dir() ? Cheers, -Tristan ___ 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 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
> Debarshi Ray 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
