diff options
author | Anders Kaseorg <andersk@MIT.EDU> | 2013-09-27 06:23:55 -0400 |
---|---|---|
committer | Jonathan Nieder <jrnieder@gmail.com> | 2013-09-27 16:06:44 -0700 |
commit | 1c4fb136dbad762c9c4350ee79c3474ae8037587 (patch) | |
tree | b5a4b7d74ad1076b9ed858f8a1478adc9bb1f2cd /merge.c | |
parent | 02a110ad435a6ccda648f09f94e546dfd7bdd0ac (diff) | |
download | git-1c4fb136dbad762c9c4350ee79c3474ae8037587.tar.gz |
submodule foreach: skip eval for more than one argumentak/submodule-foreach-quoting
'eval "$@"' creates an extra layer of shell interpretation, which is
probably not expected by a user who passes multiple arguments to git
submodule foreach:
$ git grep "'"
[searches for single quotes]
$ git submodule foreach git grep "'"
Entering '[submodule]'
/usr/lib/git-core/git-submodule: 1: eval: Syntax error: Unterminated quoted string
Stopping at '[submodule]'; script returned non-zero status.
To fix this, if the user passes more than one argument, execute "$@"
directly instead of passing it to eval.
Examples:
* Typical usage when adding an extra level of quoting is to pass a
single argument representing the entire command to be passed to the
shell. This doesn't change that.
* One can imagine someone feeding untrusted input as an argument:
git submodule foreach git grep "$variable"
That currently results in a nonobvious shell code injection
vulnerability. Executing the command named by the arguments
directly, as in this patch, fixes it.
Signed-off-by: Anders Kaseorg <andersk@mit.edu>
Acked-by: Johan Herland <johan@herland.net>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Diffstat (limited to 'merge.c')
0 files changed, 0 insertions, 0 deletions