Ideas to optimize this getitem/eval call?
steve at REMOVE-THIS-cybersource.com.au
Sun Jan 4 03:11:56 CET 2009
On Sat, 03 Jan 2009 04:14:14 -0800, mario wrote:
> On Jan 3, 7:16 am, Steven D'Aprano <st... at REMOVE-THIS-
> cybersource.com.au> wrote:
>> I must say though, your choice of builtins to prohibit seems rather
>> arbitrary. What is dangerous about (e.g.) id() and isinstance()?
> Preventive, probably. I also feel that temlates should have any business
> with info such as the memory addressed returnred by id(). For
> isinstance, becuase it is somewhat related to __subclasses__ that is
> known to be insecure.
It's that "probably" that worries me.
In my earlier post, I was going to say "your choice of builtins to
prohibit seems rather Cargo Cult-ish", but I decided that might be a bit
rude, and I decided to give you the benefit of the doubt. But your answer
here doesn't really give me any more confidence.
What security issues do you think you are preventing by prohibiting id()?
It is true that the id returned is a memory address in CPython, but
that's a mere implementation detail, and may not be true in other
implementations. Even if it is a memory address, so what? You can't do
anything with it except treat it as an integer. I don't see how id()
decreases security one iota.
In the absence of even a theoretical threat, banning a function that
returns an int because the int is derived from a memory address (but
can't be used as one!) makes you appear to be engaging in Cargo Cult
programming: following the ritual, without any understanding of what you
Sorry to be so harsh, especially over such a tiny little thing as the
id() function, but that's the impression it gives me, and I'm probably
not the only one. It is true that a false positive (needlessly banning a
harmless function) has less serious consequences than a false negative
(failing to ban a harmful function), but it does reduce confidence that
you know what you're doing.
Likewise for isinstance() and issubclass(). They may be related to
__subclasses__, but they don't give the caller access to __subclassess__.
So what is the actual threat you are defending against?
I'm not saying that there must be an actual in-the-wild demonstrated
vulnerability before you prohibit a built-in, but there should be at
least a plausible attack vector.
> Incidentally, I updated the page you point to clarify what is going on.
Speaking of that page, you have an obvious typo ("teh" instead of "the")
that should be fixed:
"In addition to teh above, all subclasses of BaseException..."
> I also added a link to Brett Cannon's inspiration paper on the topic of
> securing the python interpreter...
>> > except:
>> > # KeyError, NameError, AttributeError, SyntaxError, #
>> > ValueError, TypeError, IOError
>> If you want to capture seven exceptions, then capture seven exceptions,
>> not any exception.
> Absolutely not. I want to catch ALL evaluation exceptions...
I see. It wasn't clear that this was deliberate, I read it as if there
was a fixed, finite list you wanted to catch, and nothing else. You
should make sure this is clearly documented in your code.
More information about the Python-list