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
Attachment:
signature.asc
Description: PGP signature
