[Zope-dev] Re: RFC: backward compatibility of ps bindings (no resolution yet!)

[Tres Seaver]

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 at zope.com
Zope Corporation      "Zope Dealers"       http://www.zope.com