FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian Development

 
 
LinkBack Thread Tools
 
Old 09-27-2012, 04:09 AM
Josselin Mouette
 
Default ${HOME} vs. g_get_home_dir ()

Le mercredi 26 septembre 2012 23:17 +0100, Ian Jackson a crit :
> 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.

Yes, good idea! How about trying to understand why upstream does things
in a certain way, and looking at past discussions of how they came to
such decisions, instead of asking maintainers to override these
decisions because you know better?

--
.'`. 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/1348718990.5856.1.camel@tomoyo
 
Old 09-27-2012, 12:44 PM
"Bernhard R. Link"
 
Default ${HOME} vs. g_get_home_dir ()

* Russ Allbery <rra@debian.org> [120926 21:42]:
> > 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.

Though I guess changing the default upstream is hard, given the feedback
I got in tha past and the general tendency in gtk/gnome world to
consider anything not in their primary picture as obsolete and/or legacy
and thus not worth to support.
So users outside Debian would profit more to push patches to all
programs to properly prefer HOME instead of hoping to persuade upstream
of the library (and Debian would profit from having a smaller diff).

Bernhard R. Link


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20120927124400.GA13234@server.brlink.eu">http://lists.debian.org/20120927124400.GA13234@server.brlink.eu
 
Old 09-27-2012, 04:41 PM
Josselin Mouette
 
Default ${HOME} vs. g_get_home_dir ()

Le jeudi 27 septembre 2012 * 10:06 +0200, Bjørn Mork a écrit :
> This is not a technical issue at all. It is about breaking user
> expectations by breaking conventions.

No, this is about breaking YOUR expectations.

But what former SunOS 5.6 users expect is not necessarily what other
users expect.

I expect programs to use my real home, regardless of whatever crap could
have been put in the environment (and there are really too many things
that fiddle with $HOME incorrectly).

> Is it OK for Debian to break user expectations?

This question can be turned around against you in the same way.

> I believe changing XAUTHORITY from default is part of the same upstream
> problem.

Moving XAUTHORITY was part of avoiding issues on network homes.

> Although that change can be claimed to be within the limits of
> the documentation, bug reports like http://bugs.debian.org/614972
> clearly demonstrates that it breaks user expectations.

Thanks for pointing to this bug, which shows that user expectations are
not necessarily “XAUTHORITY=~/.Xauthority” but “my X server is
accessible from the outside provided I have the permissions”.

Which was solved in a much better way than just going back to the
previous set of bugs.

> There seems to be an upstream problem here which goes a lot deeper than
> a few weird defaults...

To me this looks like a classical change management problem. Just
because we did things in a certain way for 30 years doesn’t mean this
way is best.

Cheers,
--
.'`. 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/1348764073.21951.90.camel@pi0307572
 
Old 09-27-2012, 05:02 PM
Nikolaus Rath
 
Default ${HOME} vs. g_get_home_dir ()

Josselin Mouette <joss@debian.org> writes:
> Le mercredi 26 septembre 2012 23:17 +0100, Ian Jackson a crit :
>> 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.
>
> Yes, good idea! How about trying to understand why upstream does things
> in a certain way, and looking at past discussions of how they came to
> such decisions, instead of asking maintainers to override these
> decisions because you know better?

That is exactly what Ian suggested. Maybe you should read his mail
again.


Best,

-Nikolaus

--
Time flies like an arrow, fruit flies like a Banana.

PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6 02CF A9AD B7F8 AE4E 425C


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 87d317s8k6.fsf@inspiron.ap.columbia.edu">http://lists.debian.org/87d317s8k6.fsf@inspiron.ap.columbia.edu
 
Old 09-27-2012, 09:39 PM
Josh Triplett
 
Default ${HOME} vs. g_get_home_dir ()

Ivan Shmakov wrote:
> 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.

Agreed entirely. In particular, it breaks the very common use case of
running a program with sudo. "sudo foo" leaves $HOME set to the user's
home directory rather than root, so that foo will use the same
configuration either way. A user can then use sudo -H or sudo -i if
they want a more rootish environment. Other programs that don't respect
$HOME include ssh, which forces ugly workarounds like this:
sudo ssh -o UserKnownHostsFile=$HOME/.ssh/known_hosts ...

- Josh Triplett


--
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/20120927213859.GA7282@jtriplet-mobl1
 
Old 09-27-2012, 09:53 PM
Josselin Mouette
 
Default ${HOME} vs. g_get_home_dir ()

Le jeudi 27 septembre 2012 * 14:39 -0700, Josh Triplett a écrit :
> Agreed entirely. In particular, it breaks the very common use case of
> running a program with sudo. "sudo foo" leaves $HOME set to the user's
> home directory rather than root, so that foo will use the same
> configuration either way.

This is a bug in sudo. There can be very dangerous things in $HOME (such
as scriptable application configuration files), and they should clearly
be ignored in favor of those of root.

> A user can then use sudo -H or sudo -i if
> they want a more rootish environment. Other programs that don't respect
> $HOME include ssh, which forces ugly workarounds like this:
> sudo ssh -o UserKnownHostsFile=$HOME/.ssh/known_hosts ...

This is desired. Allowing to use another user’s known_hosts, which can
have been fiddled with, is dangerous.

--
.'`. 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/1348782816.21951.93.camel@pi0307572
 
Old 09-27-2012, 10:16 PM
Adam Borowski
 
Default ${HOME} vs. g_get_home_dir ()

On Thu, Sep 27, 2012 at 11:53:36PM +0200, Josselin Mouette wrote:
> Le jeudi 27 septembre 2012 * 14:39 -0700, Josh Triplett a écrit :
> > Agreed entirely. In particular, it breaks the very common use case of
> > running a program with sudo. "sudo foo" leaves $HOME set to the user's
> > home directory rather than root, so that foo will use the same
> > configuration either way.
>
> This is a bug in sudo. There can be very dangerous things in $HOME (such
> as scriptable application configuration files), and they should clearly
> be ignored in favor of those of root.

Since the user has already ran sudo, I don't see a problem. If you can add
a scriptable config file, you can arrange for that "sudo" to be a wrapper
over "/usr/bin/sudo".

> > A user can then use sudo -H or sudo -i if
> > they want a more rootish environment. Other programs that don't respect
> > $HOME include ssh, which forces ugly workarounds like this:
> > sudo ssh -o UserKnownHostsFile=$HOME/.ssh/known_hosts ...
>
> This is desired. Allowing to use another user’s known_hosts, which can
> have been fiddled with, is dangerous.

YOUR known_hosts? What Josh mentioned is using /home/you rather than /root;
if someone else can fiddle with your known_hosts and you can run arbitrary
commands through sudo, you're screwed already as files in .ssh tend to be
more secure than most other files.

--
Copyright and patents were never about promoting culture and innovations;
from the very start they were legalized bribes to give the king some income
and to let businesses get rid of competition. For some history, please read
https://en.wikipedia.org/wiki/Statute_of_Monopolies_1623


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20120927221652.GA8248@angband.pl">http://lists.debian.org/20120927221652.GA8248@angband.pl
 
Old 09-28-2012, 10:58 AM
Simon McVittie
 
Default ${HOME} vs. g_get_home_dir ()

On 27/09/12 22:53, Josselin Mouette wrote:
> Le jeudi 27 septembre 2012 14:39 -0700, Josh Triplett a crit :
>> "sudo foo" leaves $HOME set to the user's
>> home directory rather than root
>
> This is a bug in sudo. There can be very dangerous things in $HOME

It's configurable, because each of you can be right in different
situations. I think the Debian default is to clear the environment
(except for a few whitelisted variables like LANG).

If only root-equivalent ("admin") users are allowed to sudo (as seen in
an out-of-the-box Ubuntu installation, or Debian when a user is in the
sudo group), then escalating privileges is a non-issue. In this case,
Josh's version is OK: passing environment variables through doesn't let
the user do anything they couldn't do already.

If certain users are granted sudo access to certain commands but are not
otherwise root-equivalent, then Josselin is right that it's not
generally safe to pass environment variables through: it's likely that
they can subvert those commands by careful choice of environment variables.

S


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 506582D2.90302@debian.org">http://lists.debian.org/506582D2.90302@debian.org
 
Old 09-28-2012, 11:38 AM
Ian Jackson
 
Default ${HOME} vs. g_get_home_dir ()

(Resending due to a problem with mail headers.)

Josselin Mouette writes ("Re: ${HOME} vs. g_get_home_dir () [and 1 more messages]"):
> I expect programs to use my real home, regardless of whatever crap could
> have been put in the environment (and there are really too many things
> that fiddle with $HOME incorrectly).

What things fiddle with $HOME incorrectly ?

> Le jeudi 27 septembre 2012 * 10:06 +0200, Bjørn Mork a écrit :
> > I believe changing XAUTHORITY from default is part of the same upstream
> > problem.
>
> To me this looks like a classical change management problem. Just
> because we did things in a certain way for 30 years doesn’t mean this
> way is best.

On the other hand it would be a good idea to try to understand why
things were done a particular way, and what situations would break if
it were to be done a different way.

Ian.


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20581.35921.429021.810193@chiark.greenend.org.uk"> http://lists.debian.org/20581.35921.429021.810193@chiark.greenend.org.uk
 
Old 09-29-2012, 05:19 AM
Ivan Shmakov
 
Default ${HOME} vs. g_get_home_dir ()

>>>>> Simon McVittie <smcv@debian.org> writes:
>>>>> 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).

There's also the analysis at [1].

Unfortunately, it seems that the possibility of the user
/intentionally/ changing his or her own HOME was never
considered (and neither such concerns are reflected in the
documentation.) E. g.:

--cut--
It turns out that most of this time, this is irrelevant. login sets
$HOME and until you switch users, it will be left unchanged. The case
where it becomes an issue is with some "execute a program as another
user" commands. There is some difference in behavior here.
--cut--

Should the target user be a non-privileged one, my suggestion
(to only use HOME if it points to a directory which is both
accessible and owned by the “now-current” user) should relieve
the concerns listed. On the other hand, when the target user is
‘root’ (UID 0), either of these behaviors may be valid
(depending on the exact circumstances, as was noted elsewhere in
this thread), so this check shouldn't be done (should we follow
the general principle of “root knows what it wants.”)

[1] http://mail.gnome.org/archives/gtk-devel-list/2002-March/msg00066.html

--
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: 86r4pls8w9.fsf@gray.siamics.net">http://lists.debian.org/86r4pls8w9.fsf@gray.siamics.net
 

Thread Tools




All times are GMT. The time now is 09:05 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org