On Apr 10, 2009, at 10:43 AM, Martijn Faassen wrote:
...
> I know that Plone is moving away from untrusted code,

I predict they won't, but we'll see.

> and Zope 2 isn't
> using zope.security anyway.

That's immaterial.  I was talking about the use case.

> That leaves ZC's applications, which I
> imagine are based on zope.security?

Yes, not that it is really relevant to the discussion.

>> (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,

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.

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

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

Interesting. Note that Zope 3's protection system addresses this case  
while Zope 2's system doesn't. This is one of the reasons I'd like to  
see Zope 2 move to the Zope 3 protection system.

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

> If this is correct, this is interesting; we are taking on a burden  
> for a
> rather limited set of use cases.

What burden?  The protection system benefits all the use cases.  It's  
also a burden that is easily removed if you don't have these use cases.

> Unfortunately these are ZC's use cases.

They are not just 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).

Sure. If you (think you) don't need a protection system, or think you  
can design a lighter weight one that meets your needs, then don't use  
zope.security.

By far, most of the pain of Zope 3 protection system, as well as it's  
power, comes from the use of security proxies. The handling of rocks  
is a minor issue.

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.

Jim

--
Jim Fulton
Zope Corporation


_______________________________________________
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 )

Reply via email to