| Subject: | t/02_module_pod_output.t may fail if run as root |
Scenario: build and test Pod::Perldoc in a docker container. As usual in docker setups, the user in the container is root. One test fails:
$ make test
...
t/02_module_pod_output.t .. 1/7
# Failed test 'got expected output in STDOUT'
# at t/02_module_pod_output.t line 47.
# undef
# doesn't match '(?-xism:Look up Perl documentation)'
# Looks like you failed 1 test of 7.
t/02_module_pod_output.t .. Dubious, test returned 1 (wstat 256, 0x100)
Failed 1/7 subtests
...
The problem can be reproduced using the following command line:
$ /path/to/bin/perl /root/.cpan/build/Pod-Perldoc-3.28-0/blib/script/perldoc /root/.cpan/build/Pod-Perldoc-3.28-0/lib/Pod/Perldoc.pm
No documentation found for "/root/.cpan/build/Pod-Perldoc-3.28-0/lib/Pod/Perldoc.pm".
Interestingly, it works if the file is specified relatively:
$ /path/to/bin/perl /root/.cpan/build/Pod-Perldoc-3.28-0/blib/script/perldoc ./lib/Pod/Perldoc.pm
strace shows that the file is indeed not accessible if an absolute path is used:
19618 14:43:22.771835 stat("/root/.cpan/build/Pod-Perldoc-3.28-0/lib/Pod/Perldoc.pm", 0x5597f678ad40) = -1 EACCES (Permission denied) <0.000007>
So what's happening here? It seems that privilege dropping is in effect (I see also setre*uid calls in the strace log, apparently dropping to the nobody user). By default, /root is readably/accessible only for root. So the nobody user cannot open the file if specified absolutely, but it would work if specified relatively.
So what could be done here?
- First, the diagnostics could be improved. perldoc could tell that a suitable file was found in the search path, but it had not the permissions to open it.
- Maybe rethink the whole privilege dropping approach?
- The test could access the file with a relative path.
Probably most (but not all) failures on CPAN Testers may be due to this problem. See also
http://analysis.cpantesters.org/solved?distv=Pod-Perldoc-3.28#env%3A%24UID