That's everytime -n or -p is used. If tainting was employed, it defeats the purpose of using the shorthand notation in the first place.
2. Use a broad shell expansion.
This cannot be anticipated by the perl program. Perl gets @ARGV as it is from the executing shell because the shell has already done the expansion.
3. Run in an untrusted environment.
Well, even if the environment is trusted, the possibility of stray filenames can cause other types of damage. I mean, bad filenames may be created unintentionally by some other program working in tandem with perl's <ARGV>. | [reply]
[d/l]
[select] |
If tainting was employed, it defeats the purpose of using the shorthand notation in the first place.
Why? If you're using a simple -n/-p one-liner from the CLI, you can still do that with -T. Your one-liner will still run fine, except for the one time that you do have a filename ending with '|' (or starting with '<', '>' or '|'). I assume you don't have the habit of using such filenames all the time.
This cannot be anticipated by the perl program. Perl gets @ARGV as it is from the executing shell because the shell has already done the expansion.
Yes, but it can be anticipated by the person running the program.
I mean, bad filenames may be created unintentionally by some other program working in tandem with perl's <ARGV>.
Which means, the environment is untrusted. That really isn't any different from:
while (<STDIN>) { # No magic open
chomp;
unlink or die;
}
if the input is created by a program that unintentionally produces a name of an important file, you also have a problem. Again, a problem that could have been prevented by checking the data you got from the outside (and enabling tainting means Perl checks whether you've checked). | [reply]
[d/l] |
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/#.*$//'
now becomes
perl -Tpe 'BEGIN { $ENV{PATH} = "" } s/#.*$//'
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".
| [reply]
[d/l]
[select] |
From the programmer's perspective:
When you use unlink, you expect to delete a file (user supplied or otherwise).
When you use <>, you expect to read a file (user supplied or otherwise), but it doesn't.
From the user's perspective:
When asked for the name of a file to delete, you're not surprised if the file you specified gets deleted.
When providing the name of a file to read (script.pl *), you're *are* surprised if the file name gets treated as a shell command.
The problem is the divergence between the programmer's needs and the tools provided by the language. <> is the closest thing provided to what the programmer needs, so it gets used. The alternatives are just too costly in almost all circumstances.
| [reply]
[d/l]
[select] |