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

[Jim Fulton]

On Apr 10, 2009, at 12:26 PM, Martijn Faassen wrote:
...
>>> 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?

The view doesn't have to be public.  For example, the view might only  
be accessible to people with a particular role, and you might further  
limit what they can do based on the data they can access.

...

>> 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 don't see the point of a separate package. This is a very small  
corner of zope.security.
A simple API for extending the definition of rocks would be enough to  
deal with this particular issue.

Note that "considered immutable" is rather vague.  UUIDs aren't  
immutable if you're willing to be only slightly devious.  But if you  
aren't worried about that in an application, then that isn't a  
problem.  You might even choose to make truly mutable objects into  
rocks if you know your application is going to play nice.

...

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


Or tell them to use something else altogether.  It all depends on  
their use cases.  If they want a seatbelt rather than a space suit, I  
suppose a python-based proxy could be good enough, although it would  
likely be too slow for that environment.

Jim

--
Jim Fulton
Zope Corporation