Fix for RT#113422 is buggy and needs to be fixed for inaccesible directories (like PERL5LIB) #14177

p5pRT · 2014-10-24T11:39:24Z

Migrated from rt.perl.org#123042 (status was 'resolved')

Searchable as RT123042$

p5pRT · 2014-10-24T11:39:24Z

From burak@cpan.org

Created by burak@cpan.org

I'm copying the original report from Luciano Rocha in RT#113422
here (see the additions after that as well):

"
We were bitten by this fix.

The description didn't help finding the reason of the error:
-sh-4.1$ /usr/local/booking-perl/5.18.2/bin/perl5.18.2 -e 'print "@INC\n"'
/usr/local/git_tree/main/lib /usr/local/booking-perl/5.18.2/site/lib /usr/local/booking-perl/5.18.2/lib .

-sh-4.1$ /usr/local/booking-perl/5.18.2/bin/perl5.18.2 -e 'use warnings; print "@INC\n"'
Can't locate warnings.pm: Permission denied at -e line 1.
BEGIN failed--compilation aborted at -e line 1.

-sh-4.1$ ls -l /usr/local/booking-perl/5.18.2/lib/warnings.pm
-r--r--r-- 1 root root 20624 Jan 28 2014 /usr/local/booking-perl/5.18.2/lib/warnings.pm

The problem was having a directory in PERL5LIB that had the wrong permissions.

Test case:
$ PERL5LIB=/root /usr/local/booking-perl/5.18.2/bin/perl5.18.2 -e 'use warnings; print "@INC\n"'
Can't locate warnings.pm: Permission denied at -e line 1.
BEGIN failed--compilation aborted at -e line 1.
$ PERL5LIB=/root /usr/local/booking-perl/5.14.2/bin/perl5.14.2 -e 'use warnings; print "@INC\n"'
/root /usr/local/booking-perl/5.14.2/site/lib /usr/local/booking-perl/5.14.2/lib .

So perl isn't distinguishing from "no permission to read file" and "no permission to access a component in @INC".

Could the fix be changed to only report on file permissions, or make the error more informative (include the path that gave the error, not just the module name)?

Regards.
"

Note that the fix done in RT#113422 will also trigger that fatal error even with a simple version check:

ml97053:~ bgursoy$ mkdir /tmp/test && sudo chmod 0600 /tmp/test && sudo chown root /tmp/test
ml97053:~ bgursoy$ PERL5LIB=/tmp/test perl -V:version
Can't locate Config.pm: Permission denied.
BEGIN failed--compilation aborted.

This error is cryptic, misleading and not helpful.

The directory checks should only emit a warning and fall back to the regular program flow.

Also note that such a directory can also be empty

Perl Info


Flags:
    category=core
    severity=medium

Site configuration information for perl 5.20.0:

Configured by bgursoy at Fri Sep 12 15:16:03 CEST 2014.

Summary of my perl5 (revision 5 version 20 subversion 0) configuration:
   
  Platform:
    osname=darwin, osvers=13.3.0, archname=darwin-2level
    uname='darwin ml97053 13.3.0 darwin kernel version 13.3.0: tue jun 3 21:27:35 pdt 2014; root:xnu-2422.110.17~1release_x86_64 x86_64 '
    config_args='-Dprefix=/Users/bgursoy/.plenv/versions/5.20.0 -de -Dusedevel -A'eval:scriptdir=/Users/bgursoy/.plenv/versions/5.20.0/bin''
    hint=recommended, useposix=true, d_sigaction=define
    useithreads=undef, usemultiplicity=undef
    use64bitint=define, use64bitall=define, uselongdouble=undef
    usemymalloc=n, bincompat5005=undef
  Compiler:
    cc='cc', ccflags ='-fno-common -DPERL_DARWIN -fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include -I/opt/local/include',
    optimize='-O3',
    cppflags='-fno-common -DPERL_DARWIN -fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include -I/opt/local/include'
    ccversion='', gccversion='4.2.1 Compatible Apple LLVM 5.1 (clang-503.0.40)', gccosandvers=''
    intsize=4, longsize=8, ptrsize=8, doublesize=8, byteorder=12345678
    d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=16
    ivtype='long', ivsize=8, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8
    alignbytes=8, prototype=define
  Linker and Libraries:
    ld='env MACOSX_DEPLOYMENT_TARGET=10.3 cc', ldflags =' -fstack-protector -L/usr/local/lib -L/opt/local/lib'
    libpth=/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../lib/clang/5.1/lib /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/usr/lib /usr/local/lib /opt/local/lib /usr/lib
    libs=-ldbm -ldl -lm -lutil -lc
    perllibs=-ldl -lm -lutil -lc
    libc=, so=dylib, useshrplib=false, libperl=libperl.a
    gnulibc_version=''
  Dynamic Linking:
    dlsrc=dl_dlopen.xs, dlext=bundle, d_dlsymun=undef, ccdlflags=' '
    cccdlflags=' ', lddlflags=' -bundle -undefined dynamic_lookup -L/usr/local/lib -L/opt/local/lib -fstack-protector'



@INC for perl 5.20.0:
    /Users/bgursoy/.plenv/versions/5.20.0/lib/perl5/site_perl/5.20.0/darwin-2level
    /Users/bgursoy/.plenv/versions/5.20.0/lib/perl5/site_perl/5.20.0
    /Users/bgursoy/.plenv/versions/5.20.0/lib/perl5/5.20.0/darwin-2level
    /Users/bgursoy/.plenv/versions/5.20.0/lib/perl5/5.20.0
    .


Environment for perl 5.20.0:
    DYLD_LIBRARY_PATH (unset)
    HOME=/Users/bgursoy
    LANG (unset)
    LANGUAGE (unset)
    LC_CTYPE=UTF-8
    LD_LIBRARY_PATH (unset)
    LOGDIR (unset)
    PATH=/Users/bgursoy/.plenv/versions/5.20.0/bin:/Users/bgursoy/.plenv/libexec:/Users/bgursoy/.plenv/plugins/perl-build/bin:/opt/local/bin:/opt/local/sbin:/Users/bgursoy/.plenv/shims:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/opt/local/bin:/Users/bgursoy/bin:~/.plenv/bin:/opt/burak/prog/bin
    PERLCRITIC=/Users/bgursoy/projects/CPAN/tools/builder/.perlcriticrc
    PERL_BADLANG (unset)
    SHELL=/bin/bash

p5pRT · 2014-10-25T05:20:06Z

From @ap

* via RT <perlbug-followup@perl.org> [2014-10-24 15:25]:

So perl isn't distinguishing from "no permission to read file" and "no
permission to access a component in @INC".

Because it can’t. Perl never tries to access parts of the path, it just
tries to open the file it wants (i.e. here it tries to open warnings.pm
inside one @INC component). The system call to open the file just says
“Permission denied”. But the operating system doesn’t tell perl *why* it
is denying permission (whether the permissions problem is with the file
itself or any directory along its path or even something else entirely),
and perl has no way to know.

Therefore:

Could the fix be changed to only report on file permissions,

– No, it can’t.

You might imagine that perl should walk the path itself in order to
find out, but that is just a bad attempt at emulating the OS which has
no guarantee either of being portable or even working at all (e.g. you
might get *another* error on a *different* part of the path). Only the
kernel can *really* tell you why it refused to open the file you asked
for, and the kernel isn’t telling. Tough luck.

or make the error more informative (include the path that gave the
error, not just the module name)?

– Yes! And it clearly ought to.

This error is cryptic, misleading and not helpful.

The directory checks should only emit a warning and fall back to the
regular program flow.

There *are* *no* directory checks. Not in perl anyway. The directory
check is done implicitly and invisibly within the OS kernel while
traversing the file system, after the file open syscall is invoked by
perl. But the OS doesn’t report exactly which permissions are the reason
that it has denied the file access – only *that* it has.

So the best perl can do – and it ought to do that – is report the full
path it tried to access when it got a permission denied error. Otherwise
at first glance it looks to the user as though perl is complaining about
the warnings.pm file that the user knows exists, rather than complaining
about an attempt to find the file where perl isn’t allowed to look.

Also note that such a directory can also be empty

That’s completely irrelevant: neither does it make any difference, nor
is there absolutely any way for perl to find out the directory is empty,
since it doesn’t have permission to access the directory anyway.

Regards,
--
Aristotle Pagaltzis // <http://plasmasturm.org/>

p5pRT · 2014-10-25T05:20:06Z

The RT System itself - Status changed from 'new' to 'open'

p5pRT · 2014-10-25T20:38:47Z

From @cpansprout

On Fri Oct 24 22:20:06 2014, aristotle wrote:

* via RT <perlbug-followup@perl.org> [2014-10-24 15:25]:

or make the error more informative (include the path that gave the
error, not just the module name)?

– Yes! And it clearly ought to.

Any suggestions for the wording would be much appreciated.

--

Father Chrysostomos

p5pRT · 2014-10-26T18:08:34Z

From @ap

* Father Chrysostomos via RT <perlbug-followup@perl.org> [2014-10-25 22:40]:

On Fri Oct 24 22:20:06 2014, aristotle wrote:

* via RT <perlbug-followup@perl.org> [2014-10-24 15:25]:

or make the error more informative (include the path that gave the
error, not just the module name)?

– Yes! And it clearly ought to.

Any suggestions for the wording would be much appreciated.

I’m considering something like the following:

perl -e 'BEGIN { splice @INC,2,0,"/root" } use warnings'

For comparison, the current error is

Can't locate warnings.pm: Permission denied at -e line 1.

I’d say the ideal error would be something like

Locating warnings.pm failed at $INC[2] (/root): Permission denied at -e line 1.

Unfortunately there seems to be quite a bit of code on CPAN matching on
variations of the pattern /^Can't locate /, so it might only be possible
to jam the extra info awkwardly into that structure, as in e.g.

Can't locate warnings.pm: failed at $INC[2] (/root): Permission denied at -e line 1.

Do those help?

p5pRT · 2014-11-21T16:21:03Z

From @cpansprout

On Sun Oct 26 11:08:34 2014, aristotle wrote:

* Father Chrysostomos via RT <perlbug-followup@perl.org> [2014-10-25
22:40]:

On Fri Oct 24 22:20:06 2014, aristotle wrote:

* via RT <perlbug-followup@perl.org> [2014-10-24 15:25]:

or make the error more informative (include the path that gave
the
error, not just the module name)?

– Yes! And it clearly ought to.

Any suggestions for the wording would be much appreciated.

I’m considering something like the following:

perl -e 'BEGIN { splice @INC,2,0,"/root" } use warnings'

For comparison, the current error is

Can't locate warnings.pm: Permission denied at -e line 1.

I’d say the ideal error would be something like

Locating warnings.pm failed at $INC[2] (/root): Permission denied at
-e line 1.

Unfortunately there seems to be quite a bit of code on CPAN matching
on
variations of the pattern /^Can't locate /, so it might only be
possible
to jam the extra info awkwardly into that structure, as in e.g.

Can't locate warnings.pm: failed at $INC[2] (/root): Permission denied
at -e line 1.

Do those help?

Petr Písař beat me in writing a patch, which I applied as e2ce095. I think his shorter version is just as clear.

--

Father Chrysostomos

p5pRT · 2014-11-21T16:21:05Z

@cpansprout - Status changed from 'open' to 'pending release'

p5pRT · 2015-06-02T03:41:47Z

From @khwilliamson

Thanks for submitting this ticket

The issue should be resolved with the release today of Perl v5.22. If you find that the problem persists, feel free to reopen this ticket

--
Karl Williamson for the Perl 5 porters team

p5pRT · 2015-06-02T03:41:48Z

@khwilliamson - Status changed from 'pending release' to 'resolved'

p5pRT closed this as completed Jun 2, 2015

p5pRT added Severity Medium distro-darwin type-core labels Oct 19, 2019

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Fix for RT#113422 is buggy and needs to be fixed for inaccesible directories (like PERL5LIB) #14177

Fix for RT#113422 is buggy and needs to be fixed for inaccesible directories (like PERL5LIB) #14177

p5pRT commented Oct 24, 2014

p5pRT commented Oct 24, 2014

p5pRT commented Oct 25, 2014

p5pRT commented Oct 25, 2014

p5pRT commented Oct 25, 2014

p5pRT commented Oct 26, 2014

p5pRT commented Nov 21, 2014

p5pRT commented Nov 21, 2014

p5pRT commented Jun 2, 2015

p5pRT commented Jun 2, 2015

Fix for RT#113422 is buggy and needs to be fixed for inaccesible directories (like PERL5LIB) #14177

Fix for RT#113422 is buggy and needs to be fixed for inaccesible directories (like PERL5LIB) #14177

Comments

p5pRT commented Oct 24, 2014

p5pRT commented Oct 24, 2014

From burak@cpan.org

Created by burak@cpan.org

p5pRT commented Oct 25, 2014

From @ap

p5pRT commented Oct 25, 2014

p5pRT commented Oct 25, 2014

From @cpansprout

p5pRT commented Oct 26, 2014

From @ap

p5pRT commented Nov 21, 2014

From @cpansprout

p5pRT commented Nov 21, 2014

p5pRT commented Jun 2, 2015

From @khwilliamson

p5pRT commented Jun 2, 2015