develooper Front page | perl.perl5.porters | Postings from July 2014

Re: New feature proposal : <<>> to disable magic open of ARGV

Thread Previous | Thread Next
From:
Abigail
Date:
July 28, 2014 09:02
Subject:
Re: New feature proposal : <<>> to disable magic open of ARGV
Message ID:
20140728090224.GA27342@almanda.fritz.box
On Mon, Jul 28, 2014 at 12:44:31AM +0200, Aristotle Pagaltzis wrote:
> * Abigail <abigail@abigail.be> [2014-07-27 20:00]:
> > On Sun, Jul 27, 2014 at 09:50:59AM -0400, Peter Martini wrote:
> > > On 7/25/14, Abigail <abigail@abigail.be> wrote:
> > > >
> > > > Considering that with one liners, you're typically in full control of
> > > > what you type, including the command line arguments, I'm not sure
> > > > whether just changing -n and -p, robbing the user of options, is the
> > > > right way.
> > > >
> > > >
> > > > When was the last time you couldn't write a -n/-p one liner, because
> > > > one of the arguments you wanted to give would trigger magic open, and
> > > > you didn't want that to happen?
> > >
> > > It's actually more dangerous and has sharper edges than may be
> > > initially considered.  Putting on my security hat:
> > >
> > > shell $ touch 'report6; ls -l * |'
> > > shell $ perl -pe '' report*
> > >
> > > Even with one liners, the user isn't necessarily aware of the
> > > arguments that will be processed.
> >
> > Sure, but even with magic open disabled,
> >
> >     $ perl -pe '' *
> >
> > isn't safe, as someone may have created a file starting with -e.
> 
>     $ cd `mktemp -d ./scratch-XXXXXXXXXXXX`
>     $ echo 'All clear, move along.' > test
>     $ touch -- '-edie'
>     $ perl -pe '' *
>     Died at -e line 2, <> line 1.
> 
> You are correct: that is unsafe.
> 
> > It's "not knowing what your wildcard expands to" which is the
> > dangerous thing. Magic open is just one of the thing wildcard
> > expansion can make use of. But disabling magic open doesn't make
> > wildcard expansion safe if you don't know what it expands to.
> 
>     $ perl -pe '' -- *
>     All clear, move along.
> 
> You are incorrect: that is not unsafe.
> 
> Not knowing what your wildcard expands to is not the dangerous thing.
> 
> Not knowing that wildcard expansion in general can have a semi-predicate
> problem – and then not addressing it – is the dangerous thing.
> 
> You are of course dependent on your programs and scripts to provide some
> way (such as the -- argument convention) to resolve the ambiguity. But
> perl does, so you can.
> 
> Even if you have no idea what your wildcard is going to expand to.
> 
> But with the diamond operator (and constructs which implicitly use it),
> you cannot. There is no switch you can pass or alternative you can use
> to say “I want all of these treated as filenames, regardless of what
> they look like”, like you can with filenames vs switches. You have no
> way to avoid the semi-predicate problem of the diamond operator other
> than avoiding its use entirely.


But that's what's being proposed, isn't it? A new
operator/feature/command-line switch. I'm not at all against the *option*
to disable magic open. Just like you have the *option* to stop processing
options by using '--'.

I've nothing against -N/-P for non-magic open. But that's something else
than changing -n/-p to eliminate magic open. Besides, it gives a tricky
form of security. "perl -ne '...' -- *" may be 'safe' from magic open
on perl 5.22, but it's still unsafe if you run this command on a box
that just hasn't upgraded its perl yet.



Abigail

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About