Hey, 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 untrusted code. I think that's interesting in figuring out where we can and cannot go with zope.security. [snip] >> 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. 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? [snip] >> 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 >> 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. Okay, let's just agree on the latter. :) [snip] >> 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). [snip] > 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. Regards, Martijn _______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )