Re: a problem with git describe

From: Junio C Hamano <gitster@pobox.com>
Date: Apr 26, 2022, 16:46 UTC
Message-ID: <xmqqpml3rdwx.fsf@gitster.g>
In-Reply-To: <CAPUEspiufPMZOfZFunTFYmX7KwPxsKsAeHnfBjKgosA1ZJWqzw@mail.gmail.com>

Carlo Arenas <carenas@gmail.com> writes:

> Still think that (since we are already touching this) removing the
> restriction to
> root owned directories might make sense though, ex the following (unrealistic
> example) would work:

I think it is essential to protect unsuspecting "root" user from wandering into an unfamiliar directory that happens to be a trap, i.e. I may do something like this as an admin:

    $ sudo sh
    # cd / && find usr bin ... >/var/tmp/mylist.txt
    # cd /var/tmp

with the expectation that I'd then do some text processing on the mylist.txt file, and going there first would allow me to refer to the files more easily, instead of having to say:

    # sed -e '... processing ...' </var/tmp/mylist.txt >/var/tmp/out.txt

Alas, you as an attacker have done

    $ cd /var/tmp
    $ git init
    $ edit .git/config

to wait for me. /var/tmp would be owned by 'root' but allows anybody to write to it, only forbidding people from removing other people's stuff.

Show 22 quoted lines

>   $ mkdir -p r/t
>   $ sudo chown root r
>   $ cd r && sudo git init
>   $ cd t && git status
>
> IMHO any directories above that are owned by root and might have a git
> configuration must be safe, and therefore shouldn't need to be
> explicitly exempted.
>
> I also think that Taylor's suggestion to ignore and warn instead of
> abort might be
> a better solution to the "configuration file shouldn't be trusted"
> issue which is at
> the root of this regression, and obviously doing that would make this
> change less
> critical (users will just get a warning instead of being prevented to
> do what worked
> for them before and is a safe use case)
>
> Carlo
>
> PS. yes hardcoding uid 0 as root would be avoided, not sure where yet though