Re: [PATCH v3 1/3] t: document regression git safe.directory when using sudo

From: Junio C Hamano <gitster@pobox.com>
Date: May 5, 2022, 15:50 UTC
Message-ID: <xmqqsfpof06a.fsf@gitster.g>
In-Reply-To: <nycvar.QRO.7.76.6.2205051439290.355@tvgsbejvaqbjf.bet>

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

Show 5 quoted lines

>> 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.

This part probably needs to be stressed, not just here but near the part where we require IKNOWWHATIAMDOING=YES to be set. For regular interactive boxes, this test should pretty much be useless, as on a normally configured machine with human users, it is likely that "sudo" updates/restricts PATH to a limited set of directories and exclude the path to our just-built-and-being-tested "git".

IOW, this is primarily (and likely to be solely) for a specialized CI job in a very controlled environment.

Show 14 quoted lines

>> +# 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 &&
>
> In my Ubuntu setup, `/bin/sh` is a symbolic link to `/bin/dash`, which
> does not understand the `command`. It might make more sense to use `type`
> here, but it is quite possible that `type git` uses a different output
> format than `sudo type git` if they use different shells.

So with that in mind, shell portability is still an issue, but ...

> Another complication is that the `/etc/sudoers` I have over here specifies

... /etc/sudoers (both people allowed to use and how environments are futzed with) is not. If your /etc/sudoers do not allow SUDO prereq here to pass, then that is OK.