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

[Martijn Faassen]

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