On Apr 10, 2009, at 10:43 AM, Martijn Faassen wrote: ...
I know that Plone is moving away from untrusted code,
I predict they won't, but we'll see.
and Zope 2 isn't using zope.security anyway.
That's immaterial. I was talking about the use case.
That leaves ZC's applications, which I imagine are based on zope.security?
Yes, not that it is really relevant to the discussion.
(Note that, in some ways, HTTP requests represent untrusted code. This case can often be handled by simple resource-protection schemes, although some applications can still benefit from the Zope 3 protection scheme, which can help mediate access to content when fine- grained control is needed.)
I take it that zope.security is supporting three use cases:
a) prevent an application developer for making mistakes concerning security,
Yes
or alternatively, forcing developers to think about security in-depth.
That is obviously not a goal. No one is forcing anyone to do anything. You don't have to use zope.security.
b) prevent someone from viewing something with a public view because they don't have access to content-level methods and attributes. (which I take is your "HTTP request as untrusted code" scenario).
It is an example of that scenario, yes.
(alternate strategies are Grok's, which has view-level security but allows content-level declarations about what's accessible or not. But prominent Grok users are clamoring for something closer to the traditional approach with real content level protections)
Interesting. Note that Zope 3's protection system addresses this case while Zope 2's system doesn't. This is one of the reasons I'd like to see Zope 2 move to the Zope 3 protection system.
c) allow Python/template untrusted code
Yes. This is where proper handling of "rocks" is most important.
As far as I now know, the only actual applications of zope.security to accomplish c) are ZC's.
I'm sure there are others. Zope 2's protection scheme addresses this use case as well, although not as well.
a) and b) would be served well enough if zope.security only cared about preventing accidental security violations.
I'm not sure what you mean by "accidental" here, but I suspect I disagree. I would agree that handling of rocks is far less important in this context.
If this is correct, this is interesting; we are taking on a burden for a rather limited set of use cases.
What burden? The protection system benefits all the use cases. It's also a burden that is easily removed if you don't have these use cases.
Unfortunately these are ZC's use cases.
They are not just ZC's use cases.
Would there be a way to isolate these use cases so that other users in the community did not have to worry about this anymore? I ask because the topic has come up a few times already (now, and with the Python-based i18n message ids a while back).
Sure. If you (think you) don't need a protection system, or think you can design a lighter weight one that meets your needs, then don't use zope.security. By far, most of the pain of Zope 3 protection system, as well as it's power, comes from the use of security proxies. The handling of rocks is a minor issue. It's worth noting that applications that don't allow untrusted code (other than the request) but that still want to use the protection system to protect content can can be much more liberal about what is treated as a rock by declaring rock classes themselves. The mechanisms support this now, although there may not be an API. Jim -- Jim Fulton Zope Corporation