On Tue Jun 27 16:16:42 2017, JKEENAN wrote:
Show quoted text> On Tue Jun 27 15:17:10 2017, SREZIC wrote:
> > On 2017-06-27 13:36:44, SREZIC wrote:
> > > At least two CPAN distributions started to fail with newer
> > > File::Path
> > > releases, probably since 2.12_008:
> > >
> > > - Email-Fingerprint-0.48
> > > - App-Module-Template-0.11
> > >
> > > The failures look like this:
> > >
> > > cannot chdir to child for cant_read: Permission denied at
> > > t/process_dirs_abs.t line 39.
> > >
> > > For Email-Fingerprint I opened an RT ticket
> > > <
https://rt.cpan.org/Ticket/Display.html?id=122241> but now I am
> > > not
> > > sure if this is an unwanted File-Path regression, so I think it's
> > > better to clarify the problem in this RT queue.
> >
> > The error message occurs in more test suites, but does not cause
> > fails
> > here:
> >
> > ./pass.Module-Path-More-0.33.x86_64-linux.3.16.0-4-
> > amd64.1497995279.10062.rpt:cannot chdir to child for
> > /var/tmp/cpansmoker-1023/2017062021/BnhiUwFgJN/3: Permission denied
> > at
> > /opt/perl-5.27.1/lib/5.27.1/File/Temp.pm line 784.
> > ./pass.ack-2.18.x86_64-linux.3.16.0-4-
> > amd64.1498084194.3756.rpt:cannot
> > chdir to child for /tmp/I5fJLRuhUW/foo: Permission denied at
> > /opt/perl-5.27.1/lib/5.27.1/File/Temp.pm line 1616.
> > ./pass.File-MoreUtil-0.60.x86_64-linux.4.9.0-3-
> > amd64.1498079189.31137.rpt:cannot chdir to child for
> > /var/tmp/cpansmoker-1023/2017062118/KkrfGZwhrD/unreadable: Permission
> > denied at /opt/perl-5.27.1/lib/5.27.1/File/Temp.pm line 784.
> > ./pass.Archive-Tar-Builder-2.5002.x86_64-linux.3.16.0-4-
> > amd64.1498088794.13009.rpt:cannot chdir to child for
> > /var/tmp/cpansmoker-1023/2017062118/2OMt1kvtKp/foo: Permission denied
> > at /opt/perl-5.27.1/lib/5.27.1/File/Temp.pm line 784.
> > ./pass.Filesys-DiskUsage-0.10.x86_64-linux.3.16.0-4-
> > amd64.1498255283.31090.rpt:cannot chdir to child for
> > /var/tmp/cpansmoker-1023/2017062203/vfl2lFJVe8/sub: Permission denied
> > at /opt/perl-5.27.1/lib/5.27.1/File/Temp.pm line 784.
>
> Yes. Run attached program app.pl, first in perl-5.26.0, (File::Path
> v2.1201) then in blead (which has been updated to File::Path v2.14).
> Results attached. This is almost certainly a consequence of the
> changes we made in order to deal with
>
https://rt.cpan.org/Ticket/Display.html?id=121951. We'll have to see
> whether we can avoid these problems without impacting the security
> changes. This will not be easy or quickly forthcoming.
>
> Thank you very much.
> Jim Keenan
The file I attached yesterday, app.pl, was modeled after t/process_dirs_abs.t in the App::Module::Template module. I now believe that the code in that test file probably does not reflect the author's intent and that, as a consequence, some of the code in app.pl is a bit misleading.
In t/process_dirs_abs.t, we have this code:
#####
ok( make_path($cant_read), 'create cant_read' );
SKIP: {
skip( 'Running under windows', 2 ) if $^O eq 'MSWin32';
ok( chmod(oct(0400), $cant_read), 'make cant_read unreadable' );
throws_ok{ _process_dirs($abs_tt2, $tmpl_vars, $abs_tmpl_path, $cant_read) } qr/\ACouldn't open directory/, '_process_dirs() fails on unreadable output path';
}
ok( remove_tree($cant_read), 'removing cant_read path' );
#####
Note this statement:
#####
chmod(oct(0400), $cant_read
#####
The author intends to change the permissions on directory $cant_read (which commence as 0775). The author probably intends to change those permissions to 0400, i.e., directory owner has read-only permissions; no group or world permissions whatsoever.
But the author's syntax for 'chmod' is almost certainly incorrect. The directory permissions end up being the rather bizarre 0256 (see second attachment from yesterday). Following the documentation in 'perldoc -f chmod', the author should have said:
#####
chmod 0400, $cant_read
#####
... or the slightly less desirable:
#####
chmod oct("0400"), $cant_read
#####
I have attached a new program, chmod-impact.pl. When I run this with older and newer versions of File::Path (via perl-5.26.0 and blead), I get satisfactory results in both cases. That is, with File::Path 2.14 I get no warnings and all my tempdirs are removed as desired.
This does not completely resolve this issue, but it does highlight the fact that File::Path::remove_tree() has never been intended to handle all possible cases of directory permissions. We'll have to start looking at the other CPAN distributions cited by Slaven.
Thank you very much.
Jim Keenan