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