Description of problem: perl has trouble with the Pod/Usage.pm module Version-Release number of selected component (if applicable): perl-5.18.4-305.fc21.x86_64 How reproducible: 100% Steps to Reproduce: $ up-down.pl --date 141121 Actual results: Can't locate Pod/Usage.pm: Permission denied at /home/dwm/perl/.../scripts/up-down.pl line 10. BEGIN failed--compilation aborted at /home/dwm/perl/.../scripts/up-down.pl line 10. Expected results: Additional info: snippet from up-down.pl: #!/usr/bin/perl use v5.14; use strict; use warnings; use Carp; $SIG{'USR2'} = sub {Carp::confess("caught SIGUSR2!");}; use Getopt::Long qw/&GetOptionsFromArray/; use Config; use English '-no_match_vars'; use File::Basename; use File::Spec::Functions; use Pod::Usage; <------------ line 10 Tried with 'setenforce Permissive', no change. No AVCs or anything. Commenting the line out works around it. But jees, this breaks about 75% of my perl scripts, going back for years worth.
The Pod::Usage module is shipped in a separate package and not as part of the main perl-package. # repoquery --whatprovides 'perl(Pod::Usage)' perl-Pod-Usage-4:1.64-2.fc21.noarch => Try yum install 'perl(Pod::Usage)' or yum install perl-Pod_Usage and then rerun your script. I am closing this bug for now, because it seems to me you simply missed to install this package. Feel free to reopen it, should I be wrong.
# yum list perl-Pod-Usage Loaded plugins: aliases, auto-update-debuginfo, changelog, fastestmirror, filter-data, fs-snapshot, keys, langpacks, list-data, : local, merge-conf, post-transaction-actions, priorities, protectbase, ps, puppetverify, refresh-updatesd, : remove-with-leaves, rpm-warm-cache, show-leaves, tmprepo, tsflags, upgrade-helper, verify, versionlock Loading mirror speeds from cached hostfile * fedora: mirror.steadfast.net * fedora-debuginfo: mirror.steadfast.net * rpmfusion-free-rawhide: mirror.nexcess.net * rpmfusion-free-rawhide-debuginfo: mirror.nexcess.net * rpmfusion-nonfree-rawhide: mirror.nexcess.net * rpmfusion-nonfree-rawhide-debuginfo: mirror.nexcess.net * updates: archive.linux.duke.edu * updates-debuginfo: archive.linux.duke.edu 0 packages excluded due to repository protections Installed Packages perl-Pod-Usage.noarch 4:1.64-2.fc21 installed # It here, and been here.
More background - all these scripts that I have (close to a hundred), when run as root, throw this error: # git-sys-filter --man Can't find any loadable formatter class in Pod::Perldoc::Toterm Pod::Perldoc::Toterm Pod::Perldoc::ToTerm Pod::Perldoc::ToTERM Pod::Simple::term Pod::Simple::term Pod::Simple::Term Pod::Simple::TERM Pod::term Pod::term Pod::Term Pod::TERM Pod::Perldoc::Totext Pod::Perldoc::Totext Pod::Perldoc::ToText Pod::Perldoc::ToTEXT Pod::Simple::text Pod::Simple::text Pod::Simple::Text Pod::Simple::TEXT Pod::text Pod::text Pod::Text Pod::TEXT Pod::Perldoc::ToPod?! Aborting at /usr/bin/perldoc line 9. Did a google, and came up with a thread that seemed to indicate there was a problem when running as root, so sez to self, oh, just ignore this for now and run them as a regular user. http://code.activestate.com/lists/perl5-porters/200430/ Alas, the error message in this bug seems a little more direct. And hoping a large and important vendor might have a little sway in persuading the powers that be there should be a 'feature' backout. :) I can see it with a one liner, with a related error message: $ perl -MPod::Usage -E 'say "hello world"' Can't locate Pod/Usage.pm: Permission denied. BEGIN failed--compilation aborted. $ $ ls -l /usr/share/perl5/vendor_perl/Pod/Usage.pm -rw-r--r--. 1 root root 26857 Jun 29 13:00 /usr/share/perl5/vendor_perl/Pod/Usage.pm $
(In reply to Doug Maxey from comment #3) > $ perl -MPod::Usage -E 'say "hello world"' > Can't locate Pod/Usage.pm: Permission denied. > BEGIN failed--compilation aborted. Sorry, I can't reproduce: $ perl -MPod::Usage -E 'say "hello world"' hello world Do you have any perl modules installed which are not fedora-rpm provided, e.g. are you mixing CPAN installed modules with yum provided one?
Either there is a real permission denial, or this is just a fuzz in module look-up made by perl and returning aa bogus error message. Minimal reproducer should be: $ perl -e 'use Pod::Usage' Does it fail either? To verify the error comes from the operating system, run the failing command under "strace" tool: $ strace -fq -- perl -e 'use Pod::Usage' [...] stat("/usr/local/lib64/perl5/Pod/Usage.pm", 0x7fff0a8b6880) = -1 ENOENT (No such file or directory) stat("/usr/local/share/perl5/Pod/Usage.pm", 0x7fff0a8b6880) = -1 ENOENT (No such file or directory) stat("/usr/lib64/perl5/vendor_perl/Pod/Usage.pm", 0x7fff0a8b6880) = -1 ENOENT (No such file or directory) stat("/usr/share/perl5/vendor_perl/Pod/Usage.pm", {st_mode=S_IFREG|0644, st_size=26857, ...}) = 0 open("/usr/share/perl5/vendor_perl/Pod/Usage.pm", O_RDONLY) = 3 [...] exit_group(0) = ? +++ exited with 0 +++ Here you can see, the file could not been found in the site directories, but it was found in the vendor no-arch directory, and opened successfully. What do you see on your system?
I've had a third-party try to reproduce Doug's problem and also fail yet the size and timestamp of the Usage.pm he listed seems correct. Strange...
Searching web for phrase perl "Can't locate" "Permission denied." results in reports where people (on Debian, Fedora, Gentoo) had some directories listed in @INC without having access there. What's reporter's @INC (run "perl -V" and look at the end)? Does the strace output have some EACCES or ENOPERM errors for those directories listen in the @INC? E.g. running as a normal user one get this error: $ PERL5LIB=/root perl -e 'use Pod::Usage' Can't locate Pod/Usage.pm: Permission denied at -e line 1. BEGIN failed--compilation aborted at -e line 1.
And exactly this non-comprehensive error message was commented <https://rt.perl.org/Public/Bug/Display.html?id=113422#txn-1309618> after upstream implemented it in the perl 5.18.
Created attachment 959634 [details] Improved error message proposed to upstream
Created attachment 960619 [details] Upstream fix
Petr, sorry for the delay, other life events have prevented me from following up. The issue is not the quality of the error message, the issue is that there should be none. I have some code with my PERL5LIB which has nothing to do with the CORE stuff. There is a Pod/Usage.pm in the correct vendor location, with perm correct from root to the leaf. Yet the DIE path is taken, regardless of whether or not the @INC path search is exhuasted. It looks to be exiting early, and prevents all the scripts from running. At least all that I have with the 'use Pod::Usage'.
(In reply to Doug Maxey from comment #11) > The issue is not the quality of the error message, the issue is that there > should be none. I have some code with my PERL5LIB which has nothing to do > with the CORE stuff. There is a Pod/Usage.pm in the correct vendor > location, with perm correct from root to the leaf. > PERL5LIB can be used for CORE stuff too. > Yet the DIE path is taken, regardless of whether or not the @INC path search > is exhuasted. It looks to be exiting early, and prevents all the scripts > from running. At least all that I have with the 'use Pod::Usage'. No. This is intended behaviour. See <https://rt.perl.org/Public/Bug/Display.html?id=113422>. Does your PERL5LIB contains inaccessible directories?
Well, yes, if the CORE stuff is being looked for. The only things in my PERL5LIB are my library stuff, no CORE. Again, this is a major change in behavior in perl where @INC was previously treated like PATH, where each element is examined, and the first with what is needed is found. It now acts completely different. I can fix this by adding 'use lib' to EACH of my scripts. But why break everyone that has a valid PERL5LIB for extensions?
Please discuss your concerns with the perl5 developers in the link I provided. There is also reasoning for this change.
Ok, turns out there was some junk older, like really older perl libs in /usr/local. So, with the security enhancement, had to clobber those. That, along with adding 'use lib ...' all is good now.
(In reply to Doug Maxey from comment #15) > > Ok, turns out there was some junk older, like really older perl libs in > /usr/local. Given this, I'm closing this bug NOTABUG. Emmanuel