When git is running inside a subdirectory of the repository,
and needs to run the clean filter, it runs it chdired back to the top of
the repository. However, if git was run with a relative --work-tree,
it passes that relative path in GIT_WORK_TREE on to the clean filter.
If git was run with eg, "--work-tree=..", the clean filter sees a work
tree that is outside the repository. It might then read files located
outside the repository. That seems like it could have security
consequences, but it's certianly a surprising problem to need to deal
with when writing a clean filter.
Brian posted a fix for a very similar bug in sequencer.c on the 14th,
so it seems likely there are other occurances of the same problem
elsewhere.
Demonstration of this bug:
joey@darkstar:~/tmp/repo>cat .gitattributes
* filter=foo
joey@darkstar:~/tmp/repo>git config filter.foo.clean
clean-filter %f
joey@darkstar:~/tmp/repo>cat ~/bin/clean-filter
#!/bin/sh
pwd >&2
echo $GIT_WORK_TREE >&2
ls "$GIT_WORK_TREE/$1"
joey@darkstar:~/tmp/repo>cd foo/bar/
joey@darkstar:~/tmp/repo/foo/bar>ls
x
joey@darkstar:~/tmp/repo/foo/bar>touch x
joey@darkstar:~/tmp/repo/foo/bar>git --work-tree=../.. ls-files --modified
/home/joey/tmp/repo
../..
ls: cannot access '../../foo/bar/x': No such file or directory
git version 2.18.0
--
see shy jo
signature.asc
Description: PGP signature
