[Zope-dev] uuid.UUID as a rock in zope.security

[Martijn Faassen]

Jim Fulton wrote:
> On Apr 10, 2009, at 9:25 AM, Martijn Faassen wrote:
[snip]
>> Protecting against workarounds is useful if you allow through the web
>> manipulation of code itself. But who is actually doing this?

> The purpose of the protection system is to protect an application  
> against untrusted code provided by people other than the application  
> develoer.  If an application has no untrusted code, then the  
> protection system isn't necessary. I'll guess that 99% of applications  
> don't support untrusted code and don't need the Zope protection  
> system(s).  The applications people build with Grok probably fall in  
> this category, or one would hope. :)

> There are some applications, such as Zope 2, Plone, and many of our  
> (ZC's) applications that support untrusted code and, for these  
> systems, the protection system is critical.  It doesn't protect the  
> application developer from herself, it protects her from the people  
> writing the untrusted code.

I know that Plone is moving away from untrusted code, and Zope 2 isn't 
using zope.security anyway. That leaves ZC's applications, which I 
imagine are based on zope.security?

 > (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, or alternatively, forcing developers to think about security 
in-depth.

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). (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)

c) allow Python/template untrusted code

As far as I now know, the only actual applications of zope.security to 
accomplish c) are ZC's.

a) and b) would be served well enough if zope.security only cared about 
preventing accidental security violations.

If this is correct, this is interesting; we are taking on a burden for a 
rather limited set of use cases. Unfortunately these are 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).

It could be that c) grows more important again over time in case of a 
"rebirth of the ZMI", but that doesn't look like it's about to happen 
any time soon. And if it does it might happen in a more limited way that 
doesn't require a sophisticated untrusted code infrastructure.

Regards,

Martijn