On Thu, May 12, 2022 at 06:00:17PM -0700, Carlo Marcelo Arenas Belón wrote: > Originally reported after release of v2.35.2 (and other maint branches) > for CVE-2022-24765 and blocking otherwise harmless commands that were > done using sudo in a repository that was owned by the user. > > Add a new test script with very basic support to allow running git > commands through sudo, so a reproduction could be implemented and that > uses only `git status` as a proxy of the issue reported. > > Note that because of the way sudo interacts with the system, a much > more complete integration with the test framework will require a lot > more work and that was therefore intentionally punted for now. > > The current implementation requires the execution of a special cleanup > function which should always be kept as the last "test" or otherwise > the standard cleanup functions will fail because they can't remove > the root owned directories that are used. This also means that if > failures are found while running, the specifics of the failure might > not be kept for further debugging and if the test was interrupted, it > will be necessary to clean the working directory manually before > restarting by running: > > $ sudo rm -rf trash\ directory.t0034-root-safe-directory/ > > The test file also uses at least one initial "setup" test that creates > a parallel execution directory under the "root" sub directory, which > should be used as top level directory for all repositories that are > used in this test file. Unlike all other tests the repository provided > by the test framework should go unused. > > Special care should be taken when invoking commands through sudo, since > the environment is otherwise independent from what the test framework > setup and might have changed the values for HOME, SHELL and dropped > several relevant environment variables for your test. Indeed `git status` > was used as a proxy because it doesn't even require commits in the > repository to work and usually doesn't require much from the environment > to run, but a future patch will add calls to `git init` and that will > fail to honor the default branch name, unless that setting is NOT > provided through an environment variable (which means even a CI run > could fail that test if enabled incorrectly). > > A new SUDO prerequisite is provided that does some sanity checking > to make sure the sudo command that will be used allows for passwordless > execution as root without restrictions and doesn't mess with git's > execution path. This matches what is provided by the macOS agents that > are used as part of GitHub actions and probably nowhere else. > > Most of those characteristics make this test mostly only suitable for > CI, but it might be executed locally if special care is taken to provide > for all of them in the local configuration and maybe making use of the > sudo credential cache by first invoking sudo, entering your password if > needed, and then invoking the test with: > > $ GIT_TEST_ALLOW_SUDO=YES ./t0034-root-safe-directory.sh > > If it fails to run, then it means your local setup wouldn't work for the > test because of the configuration sudo has or other system settings, and > things that might help are to comment out sudo's secure_path config, and > make sure that the account you are using has no restrictions on the > commands it can run through sudo, just like is provided for the user in > the CI. > > For example (assuming a username of marta for you) something probably > similar to the following entry in your /etc/sudoers (or equivalent) file: > > marta ALL=(ALL:ALL) NOPASSWD: ALL > > Reported-by: SZEDER Gábor <szeder.dev@xxxxxxxxx> > Helped-by: Phillip Wood <phillip.wood123@xxxxxxxxx> > Signed-off-by: Carlo Marcelo Arenas Belón <carenas@xxxxxxxxx> > Signed-off-by: Junio C Hamano <gitster@xxxxxxxxx> > --- > t/t0034-root-safe-directory.sh | 44 ++++++++++++++++++++++++++++++++++ > 1 file changed, 44 insertions(+) > create mode 100755 t/t0034-root-safe-directory.sh > > diff --git a/t/t0034-root-safe-directory.sh b/t/t0034-root-safe-directory.sh > new file mode 100755 > index 00000000000..f6a5d63ff41 > --- /dev/null > +++ b/t/t0034-root-safe-directory.sh > @@ -0,0 +1,44 @@ > +#!/bin/sh > + > +test_description='verify safe.directory checks while running as root' > + > +. ./test-lib.sh > + > +if [ "$GIT_TEST_ALLOW_SUDO" != "YES" ] > +then > + skip_all="You must set env var GIT_TEST_ALLOW_SUDO=YES in order to run this test" > + test_done > +fi > + > +test_lazy_prereq SUDO ' > + sudo -n id -u >u && > + id -u root >r && > + test_cmp u r && > + command -v git >u && > + sudo command -v git >r && 'command' is a shell builtin, thus it's not something 'sudo' can execute, so this prereq fails with: [...] + command -v git + sudo command -v git sudo: command: command not found error: last command exited with $?=1 prerequisite SUDO not satisfied ok 1 # skip setup (missing SUDO) Changing it to: sudo sh -c "command -v git" >r && makes it work, but then it lists the path of the system git binary instead of the one that's supposed to be tested, so the prereq is still not satisfied (this is why the commit message suggested adjusting that secure_path config, right? I haven't got that far yet.) > + test_cmp u r > +' > + > +test_expect_success SUDO 'setup' ' > + sudo rm -rf root && > + mkdir -p root/r && > + ( > + cd root/r && > + git init > + ) > +' > + > +test_expect_failure SUDO 'sudo git status as original owner' ' > + ( > + cd root/r && > + git status && > + sudo git status > + ) > +' > + > +# this MUST be always the last test > +test_expect_success SUDO 'cleanup' ' > + sudo rm -rf root > +' > + > +test_done > -- > 2.36.1.371.g0fb0ef0c8d >
