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
