Jim Fulton wrote:
> On Apr 10, 2009, at 10:43 AM, Martijn Faassen wrote:
>> and Zope 2 isn't
>> using zope.security anyway.
> That's immaterial. I was talking about the use case.
It's hard to tell whether Zope 2 will ever adopt zope.security to
fulfill this use case - I have the impression the big apps are trying to
move away from Zope 2, and Plone at least seems to be moving away from
I think that's interesting in figuring out where we can and cannot go
>> I take it that zope.security is supporting three use cases:
>> a) prevent an application developer for making mistakes concerning
>> or alternatively, forcing developers to think about security
> That is obviously not a goal. No one is forcing anyone to do anything.
> You don't have to use zope.security.
Some systems come with zope.security out of the box, such as traditional
Zope 3, meaning normal development with it forces developers to think
about this. I'm not saying this is a bad thing; it is a different
perspective on "preventing an application developer from making mistakes".
>> 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.
Do you have other examples?
>> 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.
Yes, as Stephan said, Keas.
> 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
>> 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.
Okay, let's just agree on the latter. :)
>> 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).
> 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.
This is what I was aiming at. Would it be possible to have a
zope.sandbox that builds on zope.security that does the whole untrusted
execution thing, and then we have another profile of zope.security that
just allows everything considered immutable as rocks? Can such things
exist in parallel in the same code base?
I'm not saying that if so, we're going to do the work immediately. I
just want to explore what directions we could go in if someone does want
to do the work.
People trying to port zope.security dependent code to the google app
engine seem to have yet another use case. This is fulfilled right now by
a hacked up fork that at least makes import works, even though none of
the actual functionality is there. We might want to put a knob in
zope.security to support this hack out of the box too.
Zope-Dev maillist - Zope-Dev@zope.org
** No cross posts or HTML encoding! **
(Related lists -