in reply to What restrictions are there on code execution when running perl in syntax check mode?

And if there are none, e.g. anything can be called, is this safe? What precautions do people use to make sure that code (especially someone else's code) is safe to syntax check?
One should realize, due to the nature of Perl, that you in general you cannot do a syntax check and get a useful answer without executing code. And you cannot determine whether you can do a useful syntax check without running code.

Having said that, code I either consider safe, or not safe. If I don't consider it safe, I don't care whether it has syntax errors or not. It's unsafe. I don't want to run it. Period. If code is "safe", it's not more (or less) safe to check its syntax.

  • Comment on Re: What restrictions are there on code execution when running perl in syntax check mode?

Replies are listed 'Best First'.
Re^2: What restrictions are there on code execution when running perl in syntax check mode?
by ELISHEVA (Prior) on Feb 04, 2009 at 11:23 UTC

    You make a good point, but I don't think the safety problem is reducible to "If I don't think its safe...". Just scan the web for all the people who innocently rooted themselves because they had a typo in an rm command and a foolish OS distro that didn't no-op rm / by default.

    While it is true that, by nature, Perl sometimes needs to be executed to be syntax checked, that does not necessarily preclude the use of sand-boxing techniques. For instance, a call that writes to files through a Perl library isn't (usually) needed to evaluate code further down the line. Couldn't the perl syntax checker have been/be designed to monitor certain system calls and no-op them unless a flag was explicitly set to do otherwise?

    Best, beth

      The answer is to run untrusted code under a user account that has no priviledges. None, zero, zip!

      Then, as each requirement of the code to do things that require priviledges fail, you'll get an error message and line number telling what it was trying to do and where. You can then decide on a case by case basis whether to enable the account for that purpose or not.


      Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
      "Science is about questioning the status quo. Questioning authority".
      In the absence of evidence, opinion is indistinguishable from prejudice.
      You make a good point, but I don't think the safety problem is reducible to "If I don't think its safe...". Just scan the web for all the people who innocently rooted themselves because they had a typo in an rm command and a foolish OS distro that didn't no-op rm / by default.
      I don't understand what typos have to do with it. You can make a typo on the command line as well. Furthermore, such typos aren't detected by syntax checks anyway.

      Also, with "if you think it's safe/not safe" means "would you run this code or not?". If you don't want to run it, for whatever reason, who cares it has syntax errors. If you've already decided that you want to run it, that doing a syntax check isn't more harmful.

      Couldn't the perl syntax checker have been/be designed to monitor certain system calls and no-op them unless a flag was explicitly set to do otherwise?
      Maybe. But fact it is, it doesn't. In fact, the syntax checker isn't anything special. What we call "the syntax checker" is the -c option. What -c does is to not run the program after it was compiled. There's no separate "check the syntax" part in perl. But you may tinker with the Safe module, and compile the code you worry about in the sandbox provided by the Safe module.

      Note however, that for whatever action you want to prevent, I can design a piece of code that cannot be compiled, unless that action is allowed.

      Actually I think it comes down to what is safe or not, to me what is safe is code I have read through and understand, the typo's are I think outside of what the safe issue is about. Either you have code checks and you read through and follow the flow and understand what it is doing, and have a typo somewhere that can cause unintended behavior.

      Or you end up with code that you have no idea what it is doing and it is generating behavior you do not want, and may be entirely unsecure in many respects.

      Don't confuse security and proper coding, which I think is what is happening here.
        Security and proper coding are different issues but they are closely related. Improper coding is a significant source of security vulnerabilities. Remember all of those memory overrun attacks that were so popular a few years back?.

        There are many ways to detect improper coding - reading the code, team code reviews, lint checkers, and ... checks for undefined/mis-spelt variables, mismatches of parameter types. Computers are generally better than the human eye at catching those sorts of things, which is why we write syntax checkers and compilers with rich diagnostics. That feedback isn't just for newbies learning to code.

        In Perl some of these can only be done at run-time because Perl is a loosely typed language and defines itself as it goes, but even with that limitation Perl does a fairly good job at the task if you use the warnings and strict pragmas.

        Even very, very good coders can make dangerous typos.

        Best, beth.