[Python-Dev] new security doc using object-capabilities (original) (raw)

Phillip J. Eby pje at telecommunity.com
Mon Jul 24 18:32:32 CEST 2006

At 12:50 AM 7/24/2006 -0700, Brett Cannon wrote:

OK, then I need something clarified. If you read <http://www.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/TransitionToSecurityProxies>http://www.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/TransitionToSecurityProxies , it talks about creating the proxies. I get they restrict attribute access and wrap all returned objects in proxies themselves (unless they are considered safe). But to judge whether an attribute should be returned, it checks the security context.

That depends on the checker. The proxy implementation delegates all access decisions to a "checker" object. Some checkers check permissions, but a NamesChecker just checks a statically-defined list of names.

It also mentions how access to the security policy must be available so that proper security checks can be done to either grant or deny access.

So what I want to know is if this security context is this global thing that proxies access every time to check whether something is allowed or not.

Proxies don't do that; checkers do. The default Checker implementation doesn't even look at a security context if a name is declared public (i.e., it's a NamesChecker). Look at the zope.security.checker module for details.

IOW, to make it a pure capabilities system, you would only delete code, not add any, as far as I can tell.

Or is it a per-object specification?

Each proxy can have its own checker, but an individual checker instance can be shared between proxies.

And what is the security domain for Zope proxies; objects, interpreter, running Python program, what?

There are restricted eval and exec operations to run restricted code.

The primary language limitations imposed are the lack of eval/exec by the restricted code, and lack of support for raise and try/except. Implementing these would require additional compiler hacking to add code to ensure that e.g. tracebacks get wrapped.

More information about the Python-Dev mailing list