Armin Rigo wrote:
Hi all,
On Sun, Mar 4, 2012 at 03:51, Guido van Rossum <gu...@python.org> wrote:
Could we put asserts in the places where segfaults may happen?
No. I checked Lib/test/crashers/*.py and none of them would be safe
with just a failing assert. If they were, we'd have written the
assert long ago :-( "mutation_inside_cyclegc.py" is not tied to a
particular place in the source; "loosing_mro_ref.py" requires an extra
INCREF/DECREF in a performance-critical path; etc.
Changing CPython to make it truly secure is definitely either a lost
cause or a real major effort, and pysandbox just gives another such
example. My advise is to give up and move security at some other
level.
I don't think it is as hard as all that.
All the crashers can be fixed, and with minimal effect on performance.
(although the gc module might need couple of function removed)
(Or else, if you want to play this game, there is PyPy's sandboxing,
which is just an unpolished proof a concept so far. I can challenge
anyone to attack it, and this time it includes attempts to consume too
much time or memory, to crash the process in any other way than a
clean "fatal error!" message, and more generally to exploit issues
that are dismissed by pysandbox as irrelevant.)
Using too much memory can be dealt with at one place (in the allocator).
You can't solve the too much time, without solving the halting problem,
but you can make sure all code is interruptable (i.e. Cntrl-C works).
Cheers,
Mark.
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
