From: "Samuele Pedroni" <pedronis@bluewin.ch>
> From: "Jim Fulton" <jim@zope.com>
> > For example, you can't proxy exceptions without
> > breaking exception handling. In Zope, we rely on restricted execution to
> prevent
> > certian kinds of introspection on exceptions and exception classes. In
Zope,
> we
> > also don't proxy None, because None is usually checked for identity. We
also
> don't
> > proxy strings, and numbers.
> >
> That was a question I was asking myself about proxies: exception handling.
> But I never had the time to play with it to check.
>
> Does that mean that restricted code can get unproxied instances of classic
> classes as caught exceptions?
maybe the question was unclear, but it was serious, what I was asking is
whether some restricted code can do:
try:
deliberate code to force exception
except Exception,e:
...
so that e is caught unproxied. Looking at zope/security/_proxy.c it seems this
can be the case...
then to be (likely) on the safe side, all exception class definitions for
possible e classes: like e.g.
class MyExc(Exception):
...
ought to be executed _in restricted mode_, or be "trivial/empty": something
like
class MyExc(Exception):
def __init__(self, msg):
self.message = msg
Exception.__init__(self, msg)
def __str__(self):
return self.message
is already too much rope.
Although it seems not to have the "nice" two-level-of-calls behavior of Bastion
instances, an unproxied instance of MyExc if MyExc was defined outside of
restricted execution, can be used to break out of restricted execution.
regards.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4