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

[Phillip Wood <phillip.wood123@gmail.com>]

Hi Carlo

Just a quick reply for now with some brief thoughts - I'll try and 
answer more fully tomorrow.

On 04/05/2022 14:02, Carlo Arenas wrote:
 >[...]
> 
> This is indeed a bug, my intention was that it will be called in every
> request so I need to at least make it "not lazy"

Unfortunately don't think that will work, it just evaluates the 
prerequisite when you define it and uses the cached result for each 
test. (The lazy one evaluates the prerequisite on its first use and then 
caches the result)

>> Making it lazy just means it is evaluated when it is
>> first required rather than when it is defined. You're right that we want
>> to avoid sudo hanging because it is waiting for a password. We should
>> define something like
>>
>> sudo () {
>>          command sudo -n "$@"
>> }
> 
> This gets us half way to what is needed.  Indeed I explicitly use sudo
> -n in the "prerequisite" for this reason, and originally I used a perl
> function that called sudo with a timeout and then killed it after a
> fixed time.
> 
> The problem is we ALSO don't want the tests to fail if sudo suddenly
> decides to ask for a password, so by design I wanted to detect that
> issue in the prerequisite and disable the test instead, which I
> obviously didn't get right.

I don't think we have a mechanism to do that. I think the best we can do 
is just to skip the whole file if the SUDO prerequisite fails. Depending 
on the configuration sudo will delay the expiration of the cache 
password each time it is called. In any case this test file is not going 
to take much time to run so if the prerequisite passes the tests should 
hopefully run before the cached password expires.

Another possibility is to call a function at the start of each test that 
skips the test if 'sudo -n' fails.

> [...] 
> again I think the "we are running things as root folks!!" is enough to
> trigger a "better do not set that IKNOWWHATIAMDOING" variable on me,
> but it might be my sysadmin experience talking.

It is the fact that we're not just changing the uid that is used to run 
the tests but we're changing the environment as well that I think we 
need to call out. It is not obvious that running the tests with a 
different uid will stop $HOME pointing to $TEST_DIRECTORY.


I'll try and get back to you on the other points tomorrow

Best Wishes

Phillip