in reply to On being 'critical'

There's another reason for using the three-arg open. Consider the following statement:

open(my $handle, $filename) or die "Unable to open $filename: $!";

This may look OK but it really isn't, especially if $filename is part of the user input. Consider what happens if $filename is "|rm -rf *". This actually does execute rm -rf *, try it out (well, use echo or something a little safer instead). The three-arg open doesn't suffer from this problem:

open(my $handle, '<', $filename) or die "Unable to open $filename: $!"

If $filename eq "|rm -rf *" it'll try to open a file named "|rm -rf *" (which will probably fail) and won't clobber your directory.

Your code doesn't suffer so much from this problem, because you explicitly tell open how you want the file opened. In any case the three-arg open is vastly preferable.

Replies are listed 'Best First'.
Re^2: On being 'critical'
by bart (Canon) on Dec 14, 2006 at 21:04 UTC
    You state why 3 argument open is preferable in the general case, where the file name is inpredictible, but IMO none of that applies here. I think 2 argument open is perfectly fine here. In fact, it makes more sense to use, than the 3 argument open.

    As for his choice in filehandle... *shrug* It works. Granted, as he wants to use a very localized filehandle, I think use of a my $fhandle (not our!) is warranted.

    Anyway, I do think Perl::Critic is out of line.

    p.s. Did you know the P5P refuse to fix the magical open for <>, it uses 2 argument open internally, so all your considerations apply there? Ask diotalevi about it some time, he can really get pissed off about it. Rightfully so, IMO.

[reply]
[d/l]
[select]

      I completely agree with you that the 2-arg open is fine and even prefereable in this case.

      Did you know the P5P refuse to fix the magical open for <>, it uses 2 argument open internally,

      I haven't made up my mind on this yet, but what do you see wrong with that?

      My current thinking is that the magic open only comes into play when accepting arguments from the command line. And if the user decides to type '|rm -rf' as an argument to a perl script, they could just as easily type 'rm -rf' at that same command line.

      'Fixing' it, to use the 3-arg variant would entail throwing away a bunch of useful behaviours that the user can invoke from the command line.

      Are you aware of any situation where the user could do something by supplying bad args to a magical open that they could not more easily do by simply typing them straight into the command line?

      Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
      Lingua non convalesco, consenesco et abolesco. -- Rule 1 has a caveat! -- Who broke the cabal?
      "Science is about questioning the status quo. Questioning authority".
      In the absence of evidence, opinion is indistinguishable from prejudice.
[reply]

        And if the user decides to type '|rm -rf' as an argument to a perl script, they could just as easily type 'rm -rf' at that same command line.

        What about when the script runs as a different user than the one calling the script? This could be used to run a command with greater priviledge than one normally has.

        For example, given mysetuid.pl 

        print <>;

        [download]

        An attack: 

        mysetuid.pl 'cat /etc/shadow |'

        [download]

        Well, at least taint catches this problem: 

        Insecure dependency in piped open while running with -T switch

        [download]

        Update: Oops, I guess just /etc/shadow would have worked in this case!

[reply]
[d/l]
[select]
        Did you know the P5P refuse to fix the magical open for <>, it uses 2 argument open internally,
        I haven't made up my mind on this yet, but what do you see wrong with that?
        Like diotalevi always says: it is possible, even easy, to construct files with weird filenames on Unix. Unlike on Windows, special characters are not disallowed, only inconvenient. A user can use '|rm -rf /' as a file name, and then a simple invocation of 
        perl -ne 1 *

        [download]
        is enough to delete all the files you have write access to.
        'Fixing' it, to use the 3-arg variant would entail throwing away a bunch of useful behaviours that the user can invoke from the command line.
        Indeed, that is their excuse.
[reply]
[d/l]
[select]

        With your 2-arg using <>, how do you plan to deal with the guy in marketting when he's named something cute like "<< EXTRA!! >>"?. It's a filename so it should be maximally useful to the human using it. Probably a non-geek. The name supports having useful punctuation in it. It'd be nice if perl didn't croak when it tried to read the contents of that file.

        [Added: See what sucks is this "croak or nasal-demons on bad filenames" is that the calling program can be 100% sane and not have the shell invoked at all. perhaps just an execvp. This FUBARs all perl programs using the -p and -n switches too. *grumpy*!!]

        ⠤⠤ ⠙⠊⠕⠞⠁⠇⠑⠧⠊

[reply]

In Section Seekers of Perl Wisdom