Beefy Boxes and Bandwidth Generously Provided by pair Networks
go ahead... be a heretic
 
PerlMonks  

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

by JavaFan (Canon)
on Oct 30, 2008 at 10:07 UTC ( #720434=note: print w/ replies, xml ) Need Help??


in reply to Re^4: magic-diamond <> behavior -- WHAT?!
in thread magic-diamond <> behavior -- WHAT?!

Awww man.. now I've got to taint my simple filters?
No, you only need to taint your filters if you do three things at once:
  1. Use magic open.
  2. Use a broad shell expansion.
  3. Run in an untrusted environment.
The answer to "I've untrusted data, and I may be using it in a way that can harm me" is almost always to enable tainting. We don't change operations just because someone is not careful enough when coding. I don't see why magic open should be different.

And it's not just me. On the forum where it matters, p5p, the idea gets shot down as well.


Comment on Re^5: magic-diamond <> behavior -- WHAT?!
Re^6: magic-diamond <> behavior -- WHAT?!
by repellent (Priest) on Oct 30, 2008 at 17:55 UTC
      1. Use magic open.

    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>.
      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).
          Why? If you're using a simple -n/-p one-liner from the CLI, you can still do that with -T.

        This
        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".

        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.

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://720434]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others perusing the Monastery: (10)
As of 2014-09-19 21:36 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    How do you remember the number of days in each month?











    Results (147 votes), past polls