There are many advantages to using interpreted languages. One of the obvious benefits of interpreted (as opposed to compiled) languages in my mind is dynamic typing. In some contexts, I don’t care whether foo is a string, and int, or a unique key associative container – I just care that it exists. Every program (whether executable or script, whether binary, bytecode, or ascii text) is simply a set of rules governing data manipulation. Connecting the dots, we can easily see how the power and flexibility of an interpreted language manifests itself. More times than we realize, our “rules” which govern data manipulation are, in themselves, pieces of data. This fundamental principle, when massaged a little, yields the methods by which we are granted one of the trickiest functions in modern language design. The tremendously powerful, absolutely flexible, eval(). I’ll be looking at it from a Python perspective
A mentor and former coworker of mine once warned me of the dangers of eval(). I scrutinized his arguments. I considered his position. Ultimately, the wisdom in his logic won me over, and I have, I’ll admit, looked back. But only to realize that there really is never a valid excuse to use eval(). And that’s just what they are, excuses.
With the average modern desktop processor core approaching 2 or 3 GHz, and the average modern desktop RAM meeting or besting 2GB, we are spoiled. All of us. We are lulled into a false sense of security by believing that throwing more (and better) hardware at a problem is a sufficient excuse for writing poor code, shoddy algorithms, and overall paying less attention to detail. Don’t get me wrong, Jeff’s argument is carefully thought out and well presented. But I take it with a grain of salt. In fact, lots of salt. Don’t use fast hardware as an excuse to be lazy. Where does the habit of eschewing proper paradigm and using your hardware as a crutch stop? Perhaps none of us will be renowned computer scientists, but if we continue to take the easy way out simply because our hardware allows us to do so – and we teach new programmers to do the same – how many future Turing’s and Knuth’s are we denying the opportunity to get a grasp on what’s really going on and contribute great things to the industry?
The modern interpreter is a maze of logic, grammar, instruction, and contextual analyzation. A lot more goes on than meets the eye to execute your favorite little script:
I think that any instructor worth this salt would balk at the prospect of writing that little ditty in this fashion:
print eval( ""Hello, World!"" )
Why? Because it’s entirely unnecessary. The eval() function isn’t a free lunch. You’ve got to load in environmental variables, parse the target code string, in the case of Python and similar languages, compile that text into bytecode, and THEN you’ve got to actually go ahead and execute the code. There is a much more straightforward way of doing it (previously illustrated) and so for efficiency’s sake, no argument exists to use the second form over the first.
There is also another concern. A little thing called security. As I see it, there are two basic methods of eval() invocation. The first method (call it “A”) involves eval()ing code which all or in part was contributed by a user (e.g. a human). We’re talking about something like this:
if ( sys.argc < 2 ):
print "syntax: ", argv[0], " [arg1, arg2...]"
exit( -1 )
func = eval( argv[1] )
apply( func, argv[2:] )
Here, we are running arbitrary user generated syntax right in our code. The second method (call it “B”) is when you run code that is wholely or partly contributed by some nonhuman subsystem, such as a randomization routine, a hashing algorithm, or a MySQL query. For example:
for record in result: # Where 'result' is a valid MySQL result object
func = eval( record[0] )
apply( func, record[1:] )
Both methods of using eval() are inextricably unsafe, in particular, both allow arbitrary systems (whether human or not – and more on that later) to load code into Python to be executed along with the rest of the script. When one system takes code in plain text form, and passes that code to another system for execution, that’s called injection, and it’s exactly what eval() is doing. A seasoned web developer would never intentionally leave a vehicle by which a user could inject JavaScript using their site, and similarly anyone who uses a database should be well aware of the threat posed by SQL injection. And yet time and time again developers hardcode injection into their own scripts by using eval().
You might argue that method B is a much safer alternative, since there is no direct human interaction. While there is some merit to that stance, the key is to realize that those other subsystems (the hashing algorithm, the database, the “secure” source files) are themselves vunerable to attack. If you’re eval()ing code that came from a database, and someone comprimises that database, there goes the security of your script, and the validity of anything relying upon it’s output. In effect, method B is only a roundabout way of method A. And we all know that security through obscurity offers no security at all.
Recently a professor of mine (Dr. Dale Parson, formerly of Bell Labs) set us an assignment (pdf). We are to take an incomplete script and fill in a few very small holes. The exercise itself is painfully simple, but his goal is obvious enough. Dr. Parson wants us to learn the mechanics of apply() and eval() while giving us some overall exposure to the language (Python, that is). So, strictly from an instructional point of view, I see the exercise as pretty reasonable. What I find flawed is that it perpetuates the use of eval().
I’d be willing to bet that, upon submission of this project, Dr. Parson (whether manually or via some helper script) will first run the program to see if it even works, and then open the source and check the code. In that order. In this assignment, we are prompted to write our own sort function, and then using eval() and apply() teach the script how to take the name of the sort function we’d like to use via command line arguments (e.g. sys.argv). What would happen, if I were to write a function called mysort() which conformed the the appropriate signature and peformed the requested sorting, but also annihilated the users home directory? What would stop me? Not eval(). And if he examined the code first? I could spend the time to obscure the code enough that, without explicitly looking for my having done so, he wouldn’t notice even if he did examine the code before he ran it.
And it would be his fault for using eval().
Sparing the details, his project guidelines suggest writing the following line of code, in order to get a pointer to the sort function the user wants to use:
sortfunc = eval( sys.argv[1] )
How do you check to make sure sys.argv[1] holds the name of a valid sort function? Much more straightforward (and tremendously more safe) would be to fabricate a whitelist of acceptable sort functions, like so:
whitelist = { 'mergesort': mergesort, 'splitsort': splitsort, 'mysort': mysort }And then your apply() call changes from:
apply( sortfunc, arguments )
to:
apply( whitelist[sys.argv[1]], arguments )
Granted, in this situation it’s a case of ’six of one, half a dozen of the other’ since we would be writing the function and adding it to the whitelist, and the professor would still probably run them blindly. The point is this process is done much faster, tidier, and more secure, than if we would use eval() for it. Again I stress that the difference is nil in an insignificant school project like this, but using the above example, hopefully it has become evident how leaky eval() really is.
In the past five or so years, I have had what I thought was a legitimate excuse to use eval() two (only two!) times. Each time, I got up, got a glass of water, took a stroll around the office or my apartment, sat back down, and reworked the script without eval(). And both times, the resulting code was cleaner and more concise from a design standpoint. And, because I went without eval(), the code was quicker and more secure.
I very much hope that the lecture after our project is due, the professor goes on a nice rant about the evils of eval(), and explains how this was merely an exercise to give us a taste of what kinds of things interpreted languages are capable of (most of my colleagues have only studied C++ and Java up until now), and is totally clear that in a real world application, eval() shouldn’t be touched with a thirty-nine-and-a-half-foot-pole.
Update (6/12/2009): The second chapter of this discussion: eval( “round 2″ ).
