Front page | perl.perl5.porters |
Postings from February 2017
On 02/23/2017 01:42 AM, Kenichi Ishigaki wrote:
> 2017-02-23 2:25 GMT+09:00 Dan Book <grinnz@gmail.com>:
>> On Wed, Feb 22, 2017 at 5:18 AM, Kenichi Ishigaki <kishigaki@gmail.com>
>> 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("file.pl") 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.
This was one of the considered resolutions to the problem, but we could
not find an easy way, across operating systems and configurations, to
determine which directories should be allowed or not. It was deemed
fragile and misleading.
Thread Previous