Carlo Arenas <carenas@xxxxxxxxx> writes:
> On Wed, Apr 27, 2022 at 11:54 AM Junio C Hamano <gitster@xxxxxxxxx> 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.
>> - 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.
