Linux Archive

Linux Archive (http://www.linux-archive.org/)
-   Debian Development (http://www.linux-archive.org/debian-development/)
-   -   ${HOME} vs. g_get_home_dir () (http://www.linux-archive.org/debian-development/707572-home-vs-g_get_home_dir.html)

Ivan Shmakov 09-26-2012 04:12 PM

${HOME} vs. g_get_home_dir ()
 
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-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 861uhowyp3.fsf@gray.siamics.net">http://lists.debian.org/861uhowyp3.fsf@gray.siamics.net

Simon McVittie 09-26-2012 04:49 PM

${HOME} vs. g_get_home_dir ()
 
On 26/09/12 17:12, Ivan Shmakov wrote:
> (Want to use the
> all-defaults configuration for a program? Just start it like:
> $ HOME="$(mktemp -dt -- foo.XXXXXXXX)" foo)

Debian's GLib has been patched, and actually has this precedence: G_HOME
> getpwent > HOME. This was originally intended for running things like
regression tests on buildds, where the HOME specified in /etc/passwd
typically doesn't exist or can't be written; so G_HOME gets set in
debian/rules to force the issue.

For instance, telepathy-glib uses this to make its regression tests work
on kFreeBSD (GDBus writes to g_get_home_dir() to implement D-Bus
authentication, on non-Linux platforms where it doesn't support
credentials-passing).

> Note that in contrast to traditional UNIX tools, this function
> prefers passwd entries over the HOME environment variable.
...
> I believe that this behavior is buggy. There's even a (yet
> unresolved) bug report [2] against Gimp due to this behavior

To be more precise, that bug report is that the man page contradicts
what actually happens. The maintainer appears to think the correct
solution is to fix the man page.

> 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.

That sounds like a good proposal...

> Unless there be objections (or Glib be quickly patched), I'd be
> filing a bug report against libglib2.0-0.

... but I don't think this is the right way to make it happen. Please
research previous discussion to check that you're not missing arguments
that have happened in the past, then if you still think your proposal is
the best option, take it upstream.

I can see the value in having everything follow the same precedence,
$HOME > getpwent - predictability is good. However, having Debian's GLib
contradict behaviour that is specifically documented upstream doesn't
sound as though it promotes predictability. If your proposal is good for
Debian - which I think it is - then it's equally good for upstream.

S


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 5063322B.7040305@debian.org">http://lists.debian.org/5063322B.7040305@debian.org

Ivan Shmakov 09-26-2012 05:15 PM

${HOME} vs. g_get_home_dir ()
 
>>>>> Simon McVittie <smcv@debian.org> writes:
>>>>> On 26/09/12 17:12, Ivan Shmakov wrote:

>> (Want to use the all-defaults configuration for a program? Just
>> start it like: $ HOME="$(mktemp -dt -- foo.XXXXXXXX)" foo)

> Debian's GLib has been patched, and actually has this precedence:
> G_HOME > getpwent > HOME. This was originally intended for running
> things like regression tests on buildds, where the HOME specified in
> /etc/passwd typically doesn't exist or can't be written; so G_HOME
> gets set in debian/rules to force the issue.

ACK, thanks for the hint!

[…]

>> I believe that this behavior is buggy. There's even a (yet
>> unresolved) bug report [2] against Gimp due to this behavior

> To be more precise, that bug report is that the man page contradicts
> what actually happens. The maintainer appears to think the correct
> solution is to fix the man page.

If he didn't change his mind over the past four years, that is.

>> 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.

> That sounds like a good proposal...

>> Unless there be objections (or Glib be quickly patched), I'd be
>> filing a bug report against libglib2.0-0.

> ... but I don't think this is the right way to make it happen.
> Please research previous discussion to check that you're not missing
> arguments that have happened in the past,

Any particular pointers?

A scan over the past 2.5 years of gtk-devel-list@ archives
revealed nothing, and a brief Web search has only brought more
users disappointed by this behavior (e. g., [3]) and more
explicit work-arounds (e. g., [4].)

[3] http://bugs.irssi.org/index.php?do=details&task_id=532
[4] http://zathura.pwmt.org/projects/girara/doxygen/utils_8c_source.html

> then if you still think your proposal is the best option, take it
> upstream.

> I can see the value in having everything follow the same precedence,
> $HOME > getpwent - predictability is good. However, having Debian's
> GLib contradict behaviour that is specifically documented upstream
> doesn't sound as though it promotes predictability. If your proposal
> is good for Debian - which I think it is - then it's equally good for
> upstream.

Agreed.

I guess I should raise this issue on gtk-devel-list@.

--
FSF associate member #7257


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 86r4povh7e.fsf@gray.siamics.net">http://lists.debian.org/86r4povh7e.fsf@gray.siamics.net

Simon McVittie 09-26-2012 05:26 PM

${HOME} vs. g_get_home_dir ()
 
On 26/09/12 18:15, Ivan Shmakov wrote:
>>>>>> Simon McVittie <smcv@debian.org> writes:
> > Please research previous discussion to check that you're not missing
> > arguments that have happened in the past,
>
> Any particular pointers?

Following the git history points to
<https://bugzilla.gnome.org/show_bug.cgi?id=2311>, which raises
interesting issues regarding running GUI applications from under su/sudo
(which is generally a bad idea, but back then there was little alternative).

S


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 50633AC2.3060209@debian.org">http://lists.debian.org/50633AC2.3060209@debian.org

"Bernhard R. Link" 09-26-2012 05:48 PM

${HOME} vs. g_get_home_dir ()
 
* Simon McVittie <smcv@debian.org> [120926 18:50]:
> ... but I don't think this is the right way to make it happen. Please
> research previous discussion to check that you're not missing arguments
> that have happened in the past, then if you still think your proposal is
> the best option, take it upstream.

This was already taken upstream and upstream's opinion was
"if we do this as the unix guys expect then users complain that
changing $HOME changes the home directory.".

> I can see the value in having everything follow the same precedence,
> $HOME > getpwent - predictability is good. However, having Debian's GLib
> contradict behaviour that is specifically documented upstream doesn't
> sound as though it promotes predictability.

It's nice to see this finally documented upstream. (Back in time
it claimed to get the home directory which it obviously almost
but not quite does not at all.)

The documentation for g_get_home_dir[1] also documents what a
proper program can do, it's a simple:

const char *homedir = g_getenv ("HOME");
if (!homedir)
homedir = g_get_home_dir ();

instead of using get_get_home_dir directly.

Bernhard R. Link

(And tip of the day: If you are working with multiple home directories
regulariy and get tired of badly written programs confusing the initial
home directory with the current one, setting the initial home directory to
the empty string can help in many cases (though you lose having a
default one for programs not getting one set)).

[1] For example
http://developer.gnome.org/glib/2.33/glib-Miscellaneous-Utility-Functions.html#g-get-home-dir


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20120926174814.GA7297@client.brlink.eu">http://lists.debian.org/20120926174814.GA7297@client.brlink.eu

Russ Allbery 09-26-2012 07:41 PM

${HOME} vs. g_get_home_dir ()
 
"Bernhard R. Link" <brlink@debian.org> writes:
> * Simon McVittie <smcv@debian.org> [120926 18:50]:

>> ... but I don't think this is the right way to make it happen. Please
>> research previous discussion to check that you're not missing arguments
>> that have happened in the past, then if you still think your proposal is
>> the best option, take it upstream.

> This was already taken upstream and upstream's opinion was
> "if we do this as the unix guys expect then users complain that
> changing $HOME changes the home directory.".

For what it's worth, I strongly agree with Ivan on the general principle.
There are various techniques that are useful to use when one's home
directory is in AFS that require being able to override the default home
directory for applications by setting $HOME, so this was an important
feature for us at my day job. Back in the late 1990s, we (Stanford
University) found, fixed, and submitted patches for this bug in dozens of
open source packages, mostly mail clients, with a fair bit of success
getting them upstream. It would be very sad to see that regress.

> The documentation for g_get_home_dir[1] also documents what a proper
> program can do, it's a simple:

> const char *homedir = g_getenv ("HOME");
> if (!homedir)
> homedir = g_get_home_dir ();

> instead of using get_get_home_dir directly.

Oh, I'm glad that they at least document this. But it would still be nice
if the default did the right thing.

--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 87fw641shz.fsf@windlord.stanford.edu">http://lists.debian.org/87fw641shz.fsf@windlord.stanford.edu

Ian Jackson 09-26-2012 08:47 PM

${HOME} vs. g_get_home_dir ()
 
Ivan Shmakov writes ("${HOME} vs. g_get_home_dir ()"):
> 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.

I agree with your complaint. Programs should honour $HOME for the
current user, and not use getpwuid(getuid())->pw_dir.

Using pw_dir is an acceptable workaround, I guess, if the directory is
unsuitable by reason of its permissions.

> Unless there be objections (or Glib be quickly patched), I'd be
> filing a bug report against libglib2.0-0.

Please do.

Simon McVittie writes ("Re: ${HOME} vs. g_get_home_dir ()"):
> Debian's GLib has been patched, and actually has this precedence: G_HOME
> > getpwent > HOME. This was originally intended for running things like
> regression tests on buildds, where the HOME specified in /etc/passwd
> typically doesn't exist or can't be written; so G_HOME gets set in
> debian/rules to force the issue.

I think this is plainly a workaround for the buggy failure to honour
$HOME

> To be more precise, that bug report is that the man page contradicts
> what actually happens. The maintainer appears to think the correct
> solution is to fix the man page.

Clearly if the manpage and the code disagree there is a bug. But it
seems that there is some doubt about in which direction the fix should
be made.

> That sounds like a good proposal...
>
> > Unless there be objections (or Glib be quickly patched), I'd be
> > filing a bug report against libglib2.0-0.
>
> ... but I don't think this is the right way to make it happen. Please
> research previous discussion to check that you're not missing arguments
> that have happened in the past, then if you still think your proposal is
> the best option, take it upstream.

It is certainly a good idea to research previous discussion, and give
upstream the opportunity to comment. And we should listen
respectfully to what upstream have to say. I'm a great fan of the
concept of Chesterton's Fence, especially in programming.
http://www.anotherpanacea.com/2012/09/chestertons-fence/

But I think the right way to organise and track the issue here in
Debian is a bug in our BTS.

And if upstream don't think the behaviour is wrong but we don't find
their explanation convincing, their opposition should not block the
fix in Debian. One of the useful things Debian can do for our users
is to fix mistakes made by upstreams - our wider experience, mature
governance processes and closer relationship with the users gives us
that opportunity and responsibility.

> I can see the value in having everything follow the same precedence,
> $HOME > getpwent - predictability is good. However, having Debian's GLib
> contradict behaviour that is specifically documented upstream doesn't
> sound as though it promotes predictability. If your proposal is good for
> Debian - which I think it is - then it's equally good for upstream.

Well, that's true, but of course we are entiotled to disagree with and
diverge from upstream. But first we should understand why the
decision was made.

Looking at the bug logs found so far it seems to be due to users
having difficulty with sudo etc. Ivan's proposal would address that.

Ian.


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20579.27126.474718.319824@chiark.greenend.org.uk"> http://lists.debian.org/20579.27126.474718.319824@chiark.greenend.org.uk

Josselin Mouette 09-26-2012 08:51 PM

${HOME} vs. g_get_home_dir ()
 
Le mercredi 26 septembre 2012 * 21:47 +0100, Ian Jackson a écrit :
> Ivan Shmakov writes ("${HOME} vs. g_get_home_dir ()"):
> > 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.
>
> I agree with your complaint. Programs should honour $HOME for the
> current user, and not use getpwuid(getuid())->pw_dir.

Maybe you should try and obtain a CTTE decision to patch that in glib.

--
.'`. Josselin Mouette
: :' :
`. `'
`-


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: http://lists.debian.org/1348692699.22410.37.camel@pi0307572

Ian Jackson 09-26-2012 10:17 PM

${HOME} vs. g_get_home_dir ()
 
Josselin Mouette writes ("Re: ${HOME} vs. g_get_home_dir () [and 1 more messages]"):
> Maybe you should try and obtain a CTTE decision to patch that in glib.

Surely it would be better to try to fully understand the problem, and
discuss it politely and constructively with the various people
involved. There is no need to even consider escalation at this stage.

Ian.


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20579.32511.470573.313007@chiark.greenend.org.uk"> http://lists.debian.org/20579.32511.470573.313007@chiark.greenend.org.uk

Wouter Verhelst 09-26-2012 11:27 PM

${HOME} vs. g_get_home_dir ()
 
On Wed, Sep 26, 2012 at 10:51:39PM +0200, Josselin Mouette wrote:
> Le mercredi 26 septembre 2012 * 21:47 +0100, Ian Jackson a écrit :
> > Ivan Shmakov writes ("${HOME} vs. g_get_home_dir ()"):
> > > 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.
> >
> > I agree with your complaint. Programs should honour $HOME for the
> > current user, and not use getpwuid(getuid())->pw_dir.
>
> Maybe you should try and obtain a CTTE decision to patch that in glib.

I'm not sure if this was meant as sarcasm; but if it is, I would just
like to say that I find that completely unwarranted and unnecessary.

If Ian, as a member of the TC, decides to vote against your position,
then that's just his job as member of the TC, and there's nothing wrong
with that. This is why the TC is supposed to consist of more than just
one member...

(if it wasn't meant sarcastic and I'm missing something, I'm sure I
wouldn't be the only one who'd like some more detailed explanation about
the issue you're trying to raise here. Otherwise, please drop the
attitude -- it isn't helpful)

--
The volume of a pizza of thickness a and radius z can be described by
the following formula:

pi zz a


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20120926232725.GH29910@grep.be">http://lists.debian.org/20120926232725.GH29910@grep.be


All times are GMT. The time now is 11:14 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.