http://www.perlmonks.org?node_id=720381


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


I disagree. system is an explicit call. By analogy, if I were to system(), I would pick up the kitchen knife and know better. With the magic-diamond <>, the knife may magically backstab me without me even realizing what happened ;-) I know now, but how about the uninformed?

I can respect legacy since magic open existed a long time ago. But sometimes legacy needs to change for the sake of security considerations.


Awww man.. now I've got to taint my simple filters? How is this making it easy and safe for common & simple read-only filter operations, like the one in my previous post?


At $WORK, I can trust that my environment is not hostile. But I don't trust that my environment is error-free. So, you can say it's sort of a semi-trust :-) The last thing I need to worry about is how filenames will affect my Perl filters.

Replies are listed 'Best First'.
Re^5: magic-diamond <> behavior -- WHAT?!
by JavaFan (Canon) on Oct 30, 2008 at 10:07 UTC
    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.

        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).
A reply falls below the community's threshold of quality. You may see it by logging in.