Re: regression: "96b9e0e3 config: treat user and xdg config permission problems as errors" busted git-daemon

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Jeff King <peff@xxxxxxxx> writes:

>> If the access() failed due to ENOENT, the caller will get a negative
>> return from this function and will treat it as "ok, it does not
>> exist", with the original or the updated code.  This new case is
>> treated the same way by the existing callers, i.e. pretending as if
>> there is _no_ file in that unreadable $HOME directory.
>
> Exactly.

The explanation you are replying to was meant to illustrate how this
is not "inaccessible is OK", but is "treat inaccessible as missing",
by the way.

>> That semantics sounds sane and safe to me.
>
> Thanks. I'll re-roll with a proper commit message and the fixups I
> mentioned above. I think we should still do the documentation for
> git-daemon. But it is no longer about "oops, we broke git-daemon", but
> "you may want know that we do not set HOME in case you are doing
> something tricky with config". I'll submit that with the re-roll, too.

Well, at least to me, the documentation update was never about
"oops, we broke it", but was about "be careful where the HOME you
are using actually is" from the beginning of the suggestion.  I was
actually planning to apply it to maint-1.8.1 that predates the xdg
stuff, and that is why the text only suggests to set HOME for the
config.

> Do you have an opinion on just dropping the environment variable
> completely and behaving this way all the time? It would "just fix" the
> cases people running into using su/sudo, too.

With the tightening, people who used --user=daemon, expecting that
they can later tweak the behaviour by touching ~daemon/.gitconfig,
got an early warning that they need to set HOME themselves, but with
any variant of the patch under discussion, as long as loosening is
on by default, will no longer get that benefit.

I am not yet convinced if that is a real "fix/cure".

So, no, I have not even reached the point where I can form an
opinion if this behaviour should be the default.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]