Re: [PATCH] git-compat-util: avoid failing dir ownership checks if running privileged

From: Junio C Hamano <gitster@pobox.com>
Date: Apr 27, 2022, 21:25 UTC
Message-ID: <xmqqy1zqjk0x.fsf@gitster.g>
In-Reply-To: <CAPUEsph9tUkm+JsvU6z0Wt7mtRcTCH1vbvYTEdWjNyXzdoU=vw@mail.gmail.com>

Carlo Arenas <carenas@gmail.com> writes:

Show 11 quoted lines

> On Wed, Apr 27, 2022 at 11:54 AM Junio C Hamano <gitster@pobox.com> wrote:
>
>> The "sudo sh to get a shell, chdir to /var/tmp/foo to do something"
>> use case does care---it needs to make sure that whereever it goes is
>> not part of a hostile repository.  So "if SUDO_UID is there, anything
>> goes" is not a good protection for such a use case.
>
> FWIW that was never part of the proposal, indeed making git aware of
> SUDO_ID when it is running as only as root was part of the design to
> avoid other users probably allowing repositories they don't control by
> having an evil SUDO_ID.

You forgot to quote:

    This is not a suggestion of an alternative, but is a discussion
    starter to illustrate the line along which we want to think
    about the issues.

that came before it.

Show 7 quoted lines

>>  - do the comparison between st.st_uid and strtol() result by
>>    casting both to (long).  Without this, st.st_uid has a value that
>>    needs wider than long, we cannot allow the owner of such a
>>    repository in (and I somehow feel that is unlikely to happen).
>
> do you still want to cast both sides even if discarding values that would
> overflow an uid_t?

The variable used with strtol (or strtoull or whatever) does not have to be casted. The "both sides" was primarily for the case where st.st_uid is wider than whatever integral type we used to parse and hold the value we took from the environment, to force the same truncation on st.st_uid as the truncation the environment parsing may have caused. But as I keep saying I do not think it is worth it, which means ...

>>  - or omit the third one --- tough luck for those whose UID is
>>    beyond what a long can represent (and I somehow feel that this is
>>    probably OK).

... this one.