[Python-Dev] Re: Capabilities

[Samuele Pedroni]

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.