Front page | perl.perl5.porters |
Postings from July 2014
* 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.
Regards,
--
Aristotle Pagaltzis // <http://plasmasturm.org/>
Thread Previous
|
Thread Next