Re: Potentially insecure Perl scripts

[Colin Watson <cjwatson@debian.org>]

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.)

-- 
Colin Watson                                       [cjwatson@debian.org]