Carlo Arenas <carenas@xxxxxxxxx> 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.
> $ 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
