Re: a problem with git describe
- From
Carlo Arenas <carenas@gmail.com>
- Date
- Apr 26, 2022, 17:15 UTC
- Message-ID
- <CAPUEspi9mmoxehydOctGiCddUA0QtafXwKbMnprAWUPjO=vQDw@mail.gmail.com>
- In-Reply-To
- <xmqqpml3rdwx.fsf@gitster.g>
On Tue, Apr 26, 2022 at 9:46 AM Junio C Hamano <gitster@pobox.com> wrote:
Show 23 quoted lines
> > 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
Which is a career that has ended prematurely, it seems.
Show 7 quoted lines
> $ 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.
Since we are doing stat in that directory anyway, we should be able to notice the sticky bit and not fall from that trap, but I get why "exempting root" would be a bad idea.
Carlo