Beefy Boxes and Bandwidth Generously Provided by pair Networks Cowboy Neal with Hat
Clear questions and runnable code
get the best and fastest answer
 
PerlMonks  

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

by repellent (Priest)
on Oct 30, 2008 at 01:33 UTC ( #720381=note: print w/ replies, xml ) Need Help??


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

    It's no more a security hole than "system" is. Or a kitchen knife a murder weapon. Magic open was there before the fast majority of the current Perl programmers even knew there was such a thing as Perl, and it has been documented that way.

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.

    But with the addition of a single keystroke, that filter won't execute arbitrary shell commands.

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?

    And IMO, it's always a good idea to enable tainting if you're running in an environment you cannot trust (but then, if you cannot trust the environment, is such a broad shell expansion a good idea in the first place?)

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.


Comment on Re^4: magic-diamond <> behavior -- WHAT?!
Download Code
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).
Re^5: magic-diamond <> behavior -- WHAT?!
by JavaFan (Canon) on Oct 30, 2008 at 10:14 UTC
    I know now, but how about the uninformed?
    There will always be uninformed people. That's why there's documentation. Dumbing down a language for the uninformed cripples a language. It's as useful as turning cars into bumper cars, just because someone uninformed sits behind the wheel.

      Wow. Did you really write that? The words are right there, and yet I still find their existance dubious. (:

      Perhaps you should go read the documentation. Show me a single example in the documentation of using <> correctly (based on the current implementation) and I'll show a dozen counter-examples where <> is used dangerously in the standard documentation. Of course, your example would have only fairly recently been added, since for the majority of the existence of <>, no such example existed in the standard documentation (and I didn't run into any when I browsed several sections of the latest release of the documentation just hours ago).

      Nobody is proposing crippling anything. Make getting the magical behavior require a tiny extra invocation (-Margv or similar).

      Of course, it is impossible to document how to use -i correctly, but why fix -i when it might require slight modifications to a tiny, tiny fraction of the uses of <> by people who likely bragged about the freaky thing they did when they wrote them?

      Pity the fool who read perlrun, for example, and was extra careful about evily named files by using "find -print0" and followed the helpful suggestion from the standard Perl documentation and pasted and slightly modified to get:

      find /tmp -mtime +7 -print0 | perl -n0e unlink

      into root's crontab to clean out /tmp daily.

      And, no, tainting is not what should be done in such situations. An entry in root's crontab does not need to worry about environment variables being evily set. Proposing taint checking as a band-aid for the fact that something as ubiquitous as -n and -p will leak file names into the execution stream is just silly.

      - tye        

        Maybe tainting is silly, but it is available now, not maybe tomorrow.
        I fail to see what
        find /tmp -mtime +7 -print0 | perl -n0e unlink
        has to do with magic open.

        In the above fragment, perl reads the files to unlink from STDIN, not from ARGV, and no magic open happens.

      There will always be uninformed people. That's why there's documentation.

      So you agree that either the language or the documentation should be fixed!

        Well, I think magic open should stay as is, and I know that it's documented, so I don't see a need to fix the documentation.

        But documentation patches are about the easiest patches you can make, and the most likely to be accepted. If people think the current documentation isn't good enough, by all means, instead of bickering about it, write a patch.

Log In?
Username:
Password:

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

How do I use this? | Other CB clients
Other Users?
Others lurking in the Monastery: (4)
As of 2014-04-21 05:19 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    April first is:







    Results (490 votes), past polls