| Message ID | 20220502183920.88982-2-carenas@gmail.com (mailing list archive) |
|---|---|
| State | Superseded |
| Headers | show |
| Series | fix `sudo make install` regression in maint | expand |
Carlo Marcelo Arenas Belón <carenas@gmail.com> writes: > +test_lazy_prereq SUDO ' > + sudo -n id -u >u && > + id -u root >r && > + test_cmp u r && OK. We make sure we can become root with "sudo". > + command -v git >u && > + sudo command -v git >r && > + test_cmp u r While this is not as thorough as the "make sure we see the environment intact" that I alluded to during the previous review, it at least makes sure PATH (which our test framework tweaks) is propagated down to "sudo" environment intact, which should be good enough to run just "init" and "status". Keeping things simple is good. We may have to exclude this from tests that require specialized environment like valgrind tests, but that is not of immediate concern. Will queue. > +' > + > +test_expect_success SUDO 'setup' ' > + sudo rm -rf root && > + mkdir -p root/r && > + sudo chown root root && > + ( > + 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
On Mon, May 2, 2022 at 2:35 PM Junio C Hamano <gitster@pobox.com> wrote: > > Carlo Marcelo Arenas Belón <carenas@gmail.com> writes: > > > + command -v git >u && > > + sudo command -v git >r && > > + test_cmp u r > > While this is not as thorough as the "make sure we see the > environment intact" that I alluded to during the previous review, it > at least makes sure PATH (which our test framework tweaks) is > propagated down to "sudo" environment intact, which should be good > enough to run just "init" and "status". Keeping things simple is > good. Sorry, I should have mentioned that explicitly in my response. That is not possible. sudo by design will try to minimize the environment that root is running on, so the only way to make sure git still works as expected there, is to add to that environment everything else we might need. That is why I have to invent that ugly looking "env" file and the function to import variables with it, and I was assuming that for it to be useful in the end we might need to maybe import everything "GIT*" too, but obviously I didn't want to do that now, and that is why I only did the branch name (more as an example, than as something that was strictly needed) since you mentioned that in your review and I could see how it was related to `git init` being added to the tests in the next commit. Guess I botched it in my refactoring anyway, since it also makes sense for it to be added in the next commit together with `git init`instead of here. > may have to exclude this from tests that require specialized > environment like valgrind tests, but that is not of immediate > concern. I didn't test valgrind, but I would assume it is probably broken now, as well as anything else that relies on extra environmental things. Carlo
diff --git a/t/t0034-root-safe-directory.sh b/t/t0034-root-safe-directory.sh new file mode 100755 index 00000000000..bec73fe3c10 --- /dev/null +++ b/t/t0034-root-safe-directory.sh @@ -0,0 +1,42 @@ +#!/bin/sh + +test_description='verify safe.directory checks while running as root' + +. ./test-lib.sh + +# this prerequisite should be added to all the tests, it not only prevents +# the test from failing but also warms up any authentication cache sudo +# might need to avoid asking for a password +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 && + test_cmp u r +' + +test_expect_success SUDO 'setup' ' + sudo rm -rf root && + mkdir -p root/r && + sudo chown root root && + ( + 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
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, while ignoring the repository created by the test framework, and special care should be taken when invoking commands through sudo, since the environment is otherwise independent from what the test framework expects. Indeed `git status` was used as a proxy because it doesn't even require commits in the repository to work. 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 and doesn't mess with git execution paths, but otherwise additional work will be required to ensure additional commands behave as expected and that will be addressed in a later patch. Most of those characteristics make this test mostly suitable only for CI, but it could be executed locally if special care is taken to provide for some 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 by doing: $ IKNOWWHATIAMDOING=YES ./t0034-root-safe-directory.sh Reported-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Carlo Marcelo Arenas Belón <carenas@gmail.com> --- t/t0034-root-safe-directory.sh | 42 ++++++++++++++++++++++++++++++++++ 1 file changed, 42 insertions(+) create mode 100755 t/t0034-root-safe-directory.sh