Re: Potentially insecure Perl scripts

[Alex Mestiashvili <amestia@rsh2.donotuse.de>]

On 1/23/19 6:23 PM, Colin Watson wrote:
> On Wed, Jan 23, 2019 at 06:09:39PM +0100, Alex Mestiashvili wrote:
>> On 1/23/19 5:31 PM, Colin Watson wrote:
>>> On Wed, Jan 23, 2019 at 05:23:10PM +0100, Alex Mestiashvili wrote:
>>>> On 1/23/19 4:44 PM, Vincent Lefevre wrote:
>>>>> I agree that it would be better to drop this "feature" of Perl.
>>>>> It is probably never used, and probably useless (I would rather
>>>>> use the features from the shell if I need a pipe).
>>>>
>>>> Perl's open is well documented. Quoting the perlipc:
>>>>
>>>> "it's much more efficient to process the file one line or record at a
>>>> time because then you don't have to read the whole thing into memory at
>>>> once."
>>>
>>> This is a red herring.  Prepending a pipe to a perl command doesn't
>>> require reading the whole thing into memory.
>>
>> Well, this is not never used and is not useless. I just provided a quote
>> pointing to a use case. Deciding if that is useful or not is up to you.
> 
> Ah, I see.  I think it would have been clearer what you meant with a bit
> more context, so here it is for others:
> 
>        If one can be sure that a particular program is a Perl script
>        expecting filenames in @ARGV, the clever programmer can write
>        something like this:
> 
>            % program f1 "cmd1|" - f2 "cmd2|" f3 < tmpfile
> 
>        and no matter which sort of shell it's called from, the Perl
>        program will read from the file f1, the process cmd1, standard
>        input (tmpfile in this case), the f2 file, the cmd2 command,
>        and finally the f3 file.  Pretty nifty, eh?
> 
>        You might notice that you could use backticks for much the same
>        effect as opening a pipe for reading:
> 
>            print grep { !/^(tcp|udp)/ } `netstat -an 2>&1`;
>            die "bad netstatus ($?)" if $?;
> 
>        While this is true on the surface, it's much more efficient to
>        process the file one line or record at a time because then you
>        don't have to read the whole thing into memory at once.  It
>        also gives you finer control of the whole process, letting you
>        kill off the child process early if you'd like.
> 
> (In this case, my argument is with the documentation not pointing out in
> this particular spot what the problems are with this approach.)
> 

Indeed, my answer was kind of misleading without looking into the man page.

Thanks for correcting.