Re^8: magic-diamond <> behavior -- WHAT?!

Why? If you're using a simple -n/-p one-liner from the CLI, you can still do that with -T.

This

perl -pe 's/#.*$//'
[download]

now becomes

perl -Tpe 'BEGIN { $ENV{PATH} = "" } s/#.*$//'
[download]

Here's the deal:

I agree that the one-liner still runs fine, but the shorthand notation is defeated.
I agree that taint is a good thing, but I don't need its power & nit-pickiness for such a common, simple operation.
I need to be able to whip up many safe read-only operations quickly. The current magic-diamond behavior is causing worries for me.

Yes, but it can be anticipated by the person running the program.

How? By checking the expanded filenames manually? I pass my filter to a co-worker in good spirit. "What, she ran it on a filename that ended with pipe-char "|"? Shame on her! for not knowing better that that means it will magically run a shell progra.... with 2-argument ope....."

OK, ok. I pass my tainted filter to a co-worker in good spirit. "What, she got some Insecure dependency message? It only did half the files? Oh, she must have ran into a filename that ended with pipe-char "|". Shame on her! for not knowing better that that means Perl is in taint mode which checks for... among other things... so that it doesn't run a shell progra.... with 2-argument ope.... to get around this whole stinki...."

Eyes will glaze over at the explanations above, or ignorance is bliss. Either way, Perl gets a bad rep.

That really isn't any different from:

No, it is different. Once again, your example is an explicit call to unlink. The magic-diamond implicitly performs arbitrary shell commands. "Arbitrary shell commands" is much worse than "fixed, predetermined perl function (unlink) call".

Comment on Re^8: magic-diamond <> behavior -- WHAT?! Select or Download Code

Replies are listed 'Best First'.
Re^9: magic-diamond <> behavior -- WHAT?! by JavaFan (Canon) on Oct 30, 2008 at 21:39 UTC
This `perl -pe 's/#.$//'` [download] now becomes `perl -Tpe 'BEGIN { $ENV{PATH} = "" } s/#.$//'` [download] Why? You don't want to run external commands, do you? `perl -Tpe 's/#.$//'` runs fine as long as magic open doesn't try to open a pipe to a program. But if you happen to pass `rm -rf \|` as a filename, taint will abort the program. Yes, but it can be anticipated by the person running the program. How? By checking the expanded filenames manually? I pass my filter to a co-worker in good spirit. "What, she ran it on a filename that ended with pipe-char "\|"? Shame on her! for not knowing better that that means it will magically run a shell progra.... with 2-argument ope....." No, shame on you for not telling her. Suppose you would give her 'rm', and tell her it removes all files you give it as arguments. Now she runs 'rm ', and suddenly all her directories are gone as well, because she happened to have a file called '-rf' in her directory. I think she has the right to blame you for not telling her the entire truth. BTW, suppose you, and all the other people in this thread who agree with you, manage to eliminate magic open because it's too dangerous if someone runs a program using magic open with a shell expanded '', what's next? Eliminate Getopt::? Because that could also do unexpected things if such a program is run with a shell expanded ''. No, it is different. Once again, your example is an explicit call to unlink You were talking about "other" programs unintentionally creating data (in this case, filenames) which could have unwanted effects, yet it somehow isn't serious enough to warrant enabling taint checking. I came with a similar example of an "other" program unintentionally creating data (in my case, input to the program) which could have unwanted effects. My point is that if your program relies on data which cannot be trusted, it should taint check that data. Whether it's because you're using magic open, unlink or something else.	[reply] [d/l] [select]
Re^10: magic-diamond <> behavior -- WHAT?! by repellent (Priest) on Oct 30, 2008 at 22:24 UTC
OK. I'll adopt `-T` as an idiom for my filters and will add an update to the OP. It'll at least curb the magic. Thanks :) BTW, suppose you, and all the other people in this thread who agree with you, manage to eliminate magic open because it's too dangerous if someone runs a program using magic open with a shell expanded '', what's next? Eliminate Getopt::? Because that could also do unexpected things if such a program is run with a shell expanded '*'. No. Suppose agreement is in order, fix the problem upstream, not downstream. Curb the magic because 2-argument open is a known source for exploits. Fix it in the core.	[reply] [d/l]