I completely agree with you that the 2-arg open is fine and even prefereable in this case.

Did you know the P5P refuse to fix the magical open for <>, it uses 2 argument open internally,

I haven't made up my mind on this yet, but what do you see wrong with that?

My current thinking is that the magic open only comes into play when accepting arguments from the command line. And if the user decides to type '|rm -rf' as an argument to a perl script, they could just as easily type 'rm -rf' at that same command line.

'Fixing' it, to use the 3-arg variant would entail throwing away a bunch of useful behaviours that the user can invoke from the command line.

Are you aware of any situation where the user could do something by supplying bad args to a magical open that they could not more easily do by simply typing them straight into the command line?

And if the user decides to type '|rm -rf' as an argument to a perl script, they could just as easily type 'rm -rf' at that same command line.

What about when the script runs as a different user than the one calling the script? This could be used to run a command with greater priviledge than one normally has.

For example, given mysetuid.pl

print <>;
[download]

An attack:

mysetuid.pl 'cat /etc/shadow |'
[download]

Well, at least taint catches this problem:

Insecure dependency in piped open while running with -T switch
[download]

Update: Oops, I guess just /etc/shadow would have worked in this case!

As you point out, if real and effective user ids are different, taint mode is enabled automatically. So even if a script relying upon <> is accidently given the setuid bit, nothing nasty happens. That means the attack is not an attack.

My question still stands.

---

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

Lingua non convalesco, consenesco et abolesco. -- Rule 1 has a caveat! -- Who broke the cabal?

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.

Did you know the P5P refuse to fix the magical open for <>, it uses 2 argument open internally,

I haven't made up my mind on this yet, but what do you see wrong with that?

Like diotalevi always says: it is possible, even easy, to construct files with weird filenames on Unix. Unlike on Windows, special characters are not disallowed, only inconvenient. A user can use '|rm -rf /' as a file name, and then a simple invocation of

perl -ne 1 *
[download]

is enough to delete all the files you have write access to.

'Fixing' it, to use the 3-arg variant would entail throwing away a bunch of useful behaviours that the user can invoke from the command line.

Indeed, that is their excuse.

With your 2-arg using <>, how do you plan to deal with the guy in marketting when he's named something cute like "<< EXTRA!! >>"?. It's a filename so it should be maximally useful to the human using it. Probably a non-geek. The name supports having useful punctuation in it. It'd be nice if perl didn't croak when it tried to read the contents of that file.

[Added: See what sucks is this "croak or nasal-demons on bad filenames" is that the calling program can be 100% sane and not have the shell invoked at all. perhaps just an execvp. This FUBARs all perl programs using the -p and -n switches too. *grumpy*!!]

⠤⠤ ⠙⠊⠕⠞⠁⠇⠑⠧⠊