Skip Menu |

To: "perlbug [...] perl.org" <perlbug [...] perl.org>
Subject: Perlbug Report
From: "Foley, Simon " <simon.foley [...] credit-suisse.com>
Date: Wed, 11 Feb 2015 13:24:22 +0000
Download (untitled) / with headers
text/plain 641b

 

 

Simon Foley

CREDIT SUISSE AG

Information Technology | Market Data Engineering - LDN, KFVK 143

One Cabot Square | E14 4QJ London | United Kingdom

Phone +44 20 7888 1569 | Mobile +44 79 7632 3270

simon.foley@credit-suisse.com | www.credit-suisse.com

 



==============================================================================
Please access the attached hyperlink for an important electronic communications disclaimer:
http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html

==============================================================================

Download perlbug.rep
application/octet-stream 4.3k

Message body not shown because it is not plain text.

RT-Send-CC: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 1.1k
Please see BUG ID: 123270 It appears to be assumed by the developers that to DIE when one of the @INC paths for modules exists but can not be read,is acceptable behaviour. However I believe this to be irrational. Just because e.g. one of the PERL5LIB paths exists but can not be read due to file permissions should not mean that perl dies and stops iterating through the rest of the @INC paths. One of the remaining @INC paths may well have the modules the perl scripts require just because one path can not be read in should not mean perl die's.Older versions of perl (e.g. 5.12.3) did not implement such behavior and iterated through the entire @INC Path. The problem is that in a production environment in large IT departments there are many teams that control the OS environment and the PERL5LIB variable. e.g. SYBASE's SYBASE.sh\SYBASE.env include files. somebody else adds a broken path to the PERL5LIB variable and you break all perl users! Perl5 needs to be more robust to protect from human error and only warn not DIE. Also the error message is not specific enough ... it needs to specify the PATH in the @INC that it can not read, not just the module that it is currently searching for.
RT-Send-CC: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 2.3k
On Wed Feb 11 05:37:45 2015, simon@simonfoley.net wrote: Show quoted text
> Please see BUG ID: 123270 > > It appears to be assumed by the developers that to DIE when one of the > @INC paths for modules exists but can not be read,is acceptable > behaviour. However I believe this to be irrational. Just because e.g. > one of the PERL5LIB paths exists but can not be read due to file > permissions should not mean that perl dies and stops iterating through > the rest of the @INC paths. One of the remaining @INC paths may well > have the modules the perl scripts require just because one path can > not be read in should not mean perl die's. > Older versions of perl (e.g. > 5.12.3) did not implement such behavior and iterated through the > entire @INC Path.
You are correct in thinking that perl's behavior has changed in this regard in recent versions. The change in behavior is documented in pod/perl5180delta.pod: ##### =head2 C<require> dies for unreadable files When C<require> encounters an unreadable file, it now dies. It used to ignore the file and continue searching the directories in C<@INC> [perl #113422]. ##### However, I would argue that this is an improvement, not a regression. Show quoted text
> The problem is that in a production environment in > large IT departments there are many teams that control the OS > environment and the PERL5LIB variable.
I would argue that *that* is a *broken*, insecure production environment. e.g. SYBASE's Show quoted text
> SYBASE.sh\SYBASE.env include files. somebody else adds a broken path > to the PERL5LIB variable and you break all perl users! Perl5 needs to > be more robust to protect from human error and only warn not DIE. Also > the error message is not specific enough ... it needs to specify the > PATH in the @INC that it can not read, not just the module that it is > currently searching for.
Different people and different organizations will have different opinions about this. In many organizations, if a user commits a permissions violation -- advertently or inadvertently -- the user gets an Access Denied error and no further information. To tell the user precisely how he violated permissions is to feed him information that can be used to build a map of what is permitted inside a certain system and what is not. I agree with that approach; hence, I agree with the approach perl has taken here since 5.18. Thank you very much. -- James E Keenan (jkeenan@cpan.org)
Subject: Re: [perl #123795] searching @INC shouldn't abort on a permissions error
To: James E Keenan via RT <perlbug-followup [...] perl.org>
Date: Mon, 16 Mar 2015 11:30:13 +0000
From: Dave Mitchell <davem [...] iabyn.com>
CC: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 1.2k
On Sat, Mar 14, 2015 at 04:48:31PM -0700, James E Keenan via RT wrote: Show quoted text
>Also
> > the error message is not specific enough ... it needs to specify the > > PATH in the @INC that it can not read, not just the module that it is > > currently searching for.
> > Different people and different organizations will have different > opinions about this. In many organizations, if a user commits a > permissions violation -- advertently or inadvertently -- the user gets > an Access Denied error and no further information. To tell the user > precisely how he violated permissions is to feed him information that > can be used to build a map of what is permitted inside a certain system > and what is not. I agree with that approach; hence, I agree with the > approach perl has taken here since 5.18.
Note that since 5.21.7 we now include the path in the error message: $ perl5216 -I/root -Mstrict -e 1 Can't locate strict.pm: Permission denied. BEGIN failed--compilation aborted. $ perl5217 -I/root -Mstrict -e 1 Can't locate strict.pm: /root/strict.pm: Permission denied. BEGIN failed--compilation aborted. -- "Foul and greedy Dwarf - you have eaten the last candle." -- "Hordes of the Things", BBC Radio.
RT-Send-CC: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 2.5k
On Wed Feb 11 05:37:45 2015, simon@simonfoley.net wrote: Show quoted text
> One of the remaining @INC paths may well have the modules the perl > scripts require just because one path can not be read in should not > mean perl die's. Older versions of perl (e.g. 5.12.3) did not > implement such behavior and iterated through the entire @INC Path.
… which sometimes led to people being very, very confused. The problem is, there are two cases if @INC contains /some/restricted/path: /some/restricted/path/Module.pm exists or it doesn’t exist. Now the ideal behaviour goes like this: • If /some/restricted/path/Module.pm exists but perl cannot read it due to a lack of permissions, perl should throw an error and stop. If it just goes on and loads a different Module.pm from somewhere else in @INC, that can be bewildering to debug. • If /some/restricted/path/Module.pm doesn’t exist, perl should just keep searching @INC, as you would expect. If loading modules just broke any time someone added a path to @INC which perl does not have permission to read, that will be painful in a shared install. The problem is that you cannot distinguish these cases. If perl doesn’t have permission on any of the directories in /some/restricted/path, then when it tries to open /some/restricted/path/Module.pm, it will get the *same* error both if the file exists *and* if it doesn’t. So perl cannot know whether the file exists. All it knows is that for *some* reason it doesn’t have permission to read it. So you have to make a choice: perl must either do the wrong thing if the file exists or do the wrong thing if the file doesn’t exist. And in 5.20 it was changed to do the wrong thing in the other case. Show quoted text
> Perl5 needs to be more robust to protect from human error > and only warn not DIE.
That doesn’t sound like a bad idea, actually. It should fix the original problem that some people got really confused trying to figure out why the changes they were making to a file weren’t having any effect whatsoever. (Solution: perl didn’t have permissions to load the file, so it was loading another similar file from later in @INC, so it seemed to somehow magically ignore changes to the file.) That is what the change in 5.20 was supposed to fix. Just one warning wouldn’t be enough to fully cover that case though, I think: perl should probably report *every* path involved, meaning not just the paths it skipped, but also the path it then ended up loading. So it would warn at least twice. -- Aristotle Pagaltzis // <http://plasmasturm.org/>
Date: Thu, 19 Mar 2015 18:22:18 -0400
From: Ricardo Signes <perl.p5p [...] rjbs.manxome.org>
Subject: Re: [perl #123795] searching @INC shouldn't abort on a permissions error
To: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 738b
* Aristotle Pagaltzis via RT <perlbug-followup@perl.org> [2015-03-17T08:10:31] Show quoted text
> Just one warning wouldn’t be enough to fully cover that case though, I think: > perl should probably report *every* path involved, meaning not just the paths > it skipped, but also the path it then ended up loading. So it would warn at > least twice.
Without looking at the implementation, I'd like to think it could accumulate the failed attempts and then provide them all in a single warning. Something like, but better than: Resolved %s to %s because earlier options could not be read: %s Resolved X::Y to /foo/bar/X/Y.pm because earlier options could not be read: /foo/baz/X/Y.pm /foo/quux/X/Y.pm ...but maybe it's no big deal. -- rjbs
Download signature.asc
application/pgp-signature 473b

Message body not shown because it is not plain text.



This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

For issues related to this RT instance (aka "perlbug"), please contact perlbug-admin at perl.org