develooper Front page | perl.perl5.porters | Postings from February 2017

Re: The tricky issue of do()

Thread Previous | Thread Next
Kenichi Ishigaki
February 23, 2017 00:42
Re: The tricky issue of do()
Message ID:
2017-02-23 2:25 GMT+09:00 Dan Book <>:
> On Wed, Feb 22, 2017 at 5:18 AM, Kenichi Ishigaki <>
> wrote:
>> Is it possible/reasonable to remove the . (or any insecure relative
>> directory in @INC) only when it's confirmed unreasonably insecure (not
>> by a name but by testing actual permission), in order not to affect
>> people running their scripts under a directory with proper permissions
>> like their home?
>  Any writable directory is theoretically insecure if a relative path is in
> @INC. Also, this does not really apply specifically to the topic of do().

I agree any world-writable directory is theoretically insecure, and
do("") there is a bad practice that should be warned loudly
because the file may be overwritten by someone, but I'm less sure
about a writable-only-by-trusted-users directory. It may be an issue
that a trusted application mistakenly (over)write a file or a loadable
module in the current directory which might be loaded by another
trusted application afterwards, but IMHO it's rather the user's issue
perl may or may not need to address.

I suppose the unconditional removal of . is the root of this do()
issue, and I'm wondering if making it conditional (if possible) would
mitigate the issue a little.


> -Dan

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About