Front page | perl.perl5.porters |
Postings from July 2014
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. AbigailThread Previous | Thread Next