[Tutor] Quick way to find the data type

[Danny Yoo]

On Tue, 27 Sep 2005, Bernard Lebel wrote:

> Well I understand all the security issues but unless I'm missing
> something, I don't see anything wrong here.


Hi Bernard,

The other major problem with it, besides security, is that it can
introduce certain error messages that will look inscrutable unless you
take special precautions.

Assume for the moment that the file reads bad data:

######
>>> eval("3.1.4")
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "<string>", line 1
    3.1.4
       ^
SyntaxError: unexpected EOF while parsing
######

The issue here is to use the tools that are not only powerful, but easy to
debug.  Programs that use eval() are hard to debug because the dynamic
input to eval() because another possible source of errors.  Why should
your programs have SyntaxErrors, when they're not yours?  *grin*


Of course, you can then put try/except around the eval() to handle the
situation gracefully.  But if you're going to do that, you're already
halfway near the other solution, using try/except around the other
data-converter functions like int() and float().


> This is in order to read some XML data and transfer its content to the
> parameters of a 3D animation software. Since I wrote the XML writer, I
> always know how the XML will be formatted. Also, the xml data is read
> from disk, in predefined directories. Would the tree not conform to what
> I expect the read would crash right away. Finally, the evaluation of tag
> content is transposed to parameter values.
>
> So far eval() seems to do a good job for my needs.... unless I'm
> missing a piece?

It's most likely the wrong tool here.  And people HAVE been bitten by this
before:

    http://phpxmlrpc.sourceforge.net/#security

Different language, but same exact problem.  Those folks, too, though
using eval() was fine, because it was part of the internals, and bad data
would obviously never get into those internals.

They were wrong.  But it's wrong to say that they weren't careful enough
to control the flow of data: the real conceptual error was putting in
eval() in their program in the first place.  They finally woke up and
stripped it out, after getting exploited several times.


The assumptions you make, about controlling the input, and being the only
source of the xml output, sound fine.  But you're assuming that the
environment that your program will work in will be static.  Software often
ends up being applied in places that are ridiculous and unplanned-for,
like a network application.  It's best practice to avoid unneccessary
risk, and not to court it.  *grin*

The solution that Paul McGuire outlines is just as easy to use as eval(),
once you have it in a module.  And unlike eval(), there's no exploitation
risk at all.  So the argument should really be: why would we want to use
eval()?