[Zope-dev] 2.7 branch: attribute permission problems

Chris McDonough chrism at plope.com
Tue Sep 14 22:15:30 EDT 2004


On Tue, 2004-09-14 at 21:18, Richard Jones wrote:
> On the "proposals" object though, we don't have any delaration for the
> "secure_url" attribute. If I add one, or a general
> security.setDefaultAccess("allow"), then the error goes away. This doesn't
> seem correct to me.

It sure doesn't sound right.  Just to be pedantic:  You have an object A
that has no security assertion for "secure_url".  You have an object "B"
that does.  When you access the aq context a.__of__(b) and ask it for
"secure_url" in restricted code, it refuses access.  Is that a
reasonable characterization or am I reading it wrong?

> The relevant change in CVS appears to be:
> 
> *** ../../../../Zope-2.7.2/lib/python/AccessControl/ImplPython.py 2004-02-10
> 17:46:02.000000000 +1100
> - --- AccessControl/ImplPython.py 2004-09-15 09:59:41.617423171 +1000
> ***************
> *** 551,560 ****
>               return v
> 
>           validate = SecurityManagement.getSecurityManager().validate
> - -         # Filter out the objects we can't access.
> - -         if hasattr(inst, 'aq_acquire'):
> - -             return inst.aq_acquire(name, aq_validate, validate)
> - -         # Or just try to get the attribute directly.
>           if validate(inst, inst, name, v):
>               return v
>       raise Unauthorized, name
> - --- 551,556 ----
> 
> The change note being "- Removed DWIM'y attempt to filter
> acquired-but-not-aceessible results from 'guarded_getattr'." and I'm not sure
> what that means :)

I'm sure there was a case that provoked this checkin but I think we'd
need to ask Tres what it was (and see what he thinks about its results).

- C





More information about the Zope-Dev mailing list