New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
searching @INC shouldn't abort on a permissions error #14495
Comments
From simon.foley@credit-suisse.comSimon Foley ===============================================================================
|
From simon.foley@credit-suisse.comCreated by simon@simonfoley.netPlease 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, Perl Info
|
From simon@simonfoley.netPlease 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. |
From [Unknown Contact. See original ticket]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. |
From @jkeenanOn Wed Feb 11 05:37:45 2015, simon@simonfoley.net wrote:
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: ##### When C<require> encounters an unreadable file, it now dies. It used to ##### However, I would argue that this is an improvement, not a regression.
I would argue that *that* is a *broken*, insecure production environment. e.g. SYBASE's
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. -- |
The RT System itself - Status changed from 'new' to 'open' |
From @iabynOn Sat, Mar 14, 2015 at 04:48:31PM -0700, James E Keenan via RT wrote:
Note that since 5.21.7 we now include the path in the error message: $ perl5216 -I/root -Mstrict -e 1 $ perl5217 -I/root -Mstrict -e 1 -- |
From @apOn Wed Feb 11 05:37:45 2015, simon@simonfoley.net wrote:
… 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 • If /some/restricted/path/Module.pm doesn’t exist, perl should just 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.
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. -- |
From @rjbs* Aristotle Pagaltzis via RT <perlbug-followup@perl.org> [2015-03-17T08:10:31]
Without looking at the implementation, I'd like to think it could accumulate 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: ...but maybe it's no big deal. -- |
Migrated from rt.perl.org#123795 (status was 'open')
Searchable as RT123795$
The text was updated successfully, but these errors were encountered: