Dieter Maurer wrote:

Tres Seaver wrote at 2004-1-23 17:04 -0500:

...

The script being called is invoked during a workflow transition, which calls the script, passing a StateChangeInfo instance; the new code tries to validate access to the SCI and pukes, badly, because the script has proxy roles, but the 'container' isn't wrapped. I *think* that we are seeing this issue because the new security code is tougher about checking access within the script.

But why is a "StateChangeInfo" object passed as "container" to the code above?

Just for clarity: the 'container' in play here is not the object bound as 'container' to the script; it is the argument passed to validate, which is trying to check that the script is allowed.

Up to now, I was convinced that "container" is usually (for acquisition wrappers) the equivalent to "*.aq_inner.aq_parent" (which I would prefer to have an "aq_container" for).

Hopefully, we get soon (for Zope 2.9, at least) a clear specification when "validate" is called with which arguments. It will help everyone.

...

I tried to work around the issue by adding a 'getPhysicalRoot' method to SCI, merely delegating to the underlying object; however, the script in my app then blows up on access to 'object' (which I may be able to fix as well).

I think, the security context should provide access to the root. "container" and "object" can be any type of objects neither of which may have access to the root.

I am working on a fix for both parts of this; the code in question is that part of validate which is working to ensure that a script with proxy roles is not acquiring an object "above" the current user's acl_users. Tres. -- =============================================================== Tres Seaver tseaver@zope.com Zope Corporation "Zope Dealers" http://www.zope.com