in reply to Re: Why do poisoned null attacks still work ?
in thread Why do poisoned null attacks still work ?

The function is documented to open the specified file. It should either do that or return an error, not (attempt to) open a different file.
  • Comment on Re^2: Why do poisoned null attacks still work ?

Replies are listed 'Best First'.
Re^3: Why do poisoned null attacks still work ?
by Corion (Patriarch) on Jul 22, 2009 at 15:39 UTC

    Yes, but unless you plan to replace even more of the OS by Perl, what better way of opening a file do you see than asking the OS to open it?

    Of course, Perl could try to wrap all C APIs that are known to take a C string and prevent passing a filename to them that contains a \0, but enabling Taint mode does about the same unless you're actively opening that door again.

      what better way of opening a file do you see than asking the OS to open it?

      Noone denies that open(2) will be called. The question is what else needs to be done. If your interface and the system's differ (as they do here), you need to take steps to handle incompatibilities.

      Perl could try to wrap all C APIs that are known to take a C string

      Try? They're already wrapped. Systems calls don't know anything about scalars and Perl's stack. The problem is in the conversion from scalars to C-strings, and that occurs entirely in Perl.

      Besides, "it's hard to catch every instance so we shouldn't fix any instance" is a very lame argument.

        As (the string parts of) Perl scalars always are terminated with a \0, I doubt that there is much conversion happening at the interface between Perl and the C library. But as Taint will catch this and other errors, I don't see why there should be another system.