Removal of aq_acquire from guarded_getattr
The bug: http://zope.org/Collectors/CMF/259 The fix: http://mail.zope.org/pipermail/zope-checkins/2004-August/028152.html This effectively changes how acquisition works in restricted Python. I understand this may well be the point <wink>. The consequences: Zope sites experiencing seemingly random Unauthorized errors. [1] I have added tests to the AccessControl suite on 2.7 branch that demonstrate the new behavior. Note that all of them pass in Zope 2.7.2. What it _appears_ to mean is that when a container denies access, the object security of the acquiree is checked. Therefore, a potential acquiree (read: _any_ object) must make sure to declareObjectProtected or it may end up not being acquirable. This is not always the case in current Zope/CMF/Plone which would explain the Unauthorized errors we see. Tres, I am happy to discuss this further once you had a look at the tests. I also have tests for the CMF in case you want them. Stefan [1] http://zope.org/Collectors/CMF/318 http://zope.org/Collectors/Zope/1654 http://zope.org/Collectors/Zope/1669 http://plone.org/collector/3682 -- The time has come to start talking about whether the emperor is as well dressed as we are supposed to think he is. /Pete McBreen/
The failing AccessControl tests can now be found on shh-aqtests-branch in zope.org CVS. Observations: a) guarded_getattr checks object security of the acquiree if the container denies access (at least that's my assessment). b) The tests pass when either - running Zope < 2.7.3, or - declaring object security on the acquiree via declareObjectProtected(foo) c) Unauthorized errors pop up in CMF-based applications, typically when trying to access a portal tool from a Python Script. E.g. the tests for <http://zope.org/Collectors/CMF/318> fail on 1.4 branch because 'portal_membership' can not be acquired. d) Current Zope objects are ill-prepared for these checks as many do not bother to declare object security in the first place (User Folder, Mail Host, 50% of CMF tools, ...). e) Plone and Archetypes exponentially increase the likelihood of encountering these errors. I have seen several variations in our customer projects, all reliably fixed by b) f) I think this is serious. It certainly is a problem for Plone. g) <http://mail.zope.org/pipermail/zope-checkins/2004-August/028152.html> h) If g) really is THE fix for <http://zope.org/Collectors/CMF/259> all existing Zope software must be reviewed, IMO. i) Unit tests + VerboseSecurity = useful. Please advise, Stefan -- The time has come to start talking about whether the emperor is as well dressed as we are supposed to think he is. /Pete McBreen/
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tue, 25 Jan 2005 10:30 am, Stefan H. Holek wrote:
- declaring object security on the acquiree via declareObjectProtected(foo)
For me, the problem arises when the acquiree is a Python builtin object - a string instance attribute in my case. Hence I can't make any useful statement like the above. I have a statement:: security.setDefaultAccess({'secure_url': 1}) on the class, but with the change discussed here, that assertion is never looked up. I attempted to:: security.declarePublic('secure_url') but of course that didn't change anything, as I mentioned the class assertions weren't being looked at. After poking around some more, I realised that validate() (VerboseSecurityPolicy's) was being invoked with:: aq_chain(container) = [ <CG Conference Registrations registrations at 0x4176ba00>, <CG WebSpace web at 0x41483ce0>, <CG Conference 1 at 0x4176b970>, <CG Conferences conferences at 0x41483c30>, <CGPublisher CGPublisher at 0x4176b980>, <Application instance at 4179e050>, <RequestContainer instance at 4176b9f0>] context = <AccessControl.SecurityManagement.SecurityContext instance at 0x413cabec> aq_chain(value) = ['http://secure.cgpublisher.localhost'] That is, there's no acquisition context on the simple string. To "fix" the problem, I changed secure_url to be a ComputedAttribute which looked up the instance attribute _secure_url. This then gave the value a valid acquisition chain and everything "works" now. I'm really sorry I can't be more helpful and produce a useful test case, but I've a bazillion deadlines falling on the floor. Maybe in a few months. For now I just needed a work-around that will let me run in an un-patched Zope. Richard -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFCBwoerGisBEHG6TARAqRIAJwOOCtEccg2RqsjqjzlTLkEVfvn2gCeMYRw qwFvrTuk5xxhYi0pAU+UcUo= =SOlC -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Mon, 7 Feb 2005 05:26 pm, Richard Jones wrote:
That is, there's no acquisition context on the simple string. To "fix" the problem, I changed secure_url to be a ComputedAttribute which looked up the instance attribute _secure_url. This then gave the value a valid acquisition chain and everything "works" now.
Please ignore this message. Everything does *not* work. I am at a loss as to why it worked *briefly*. Must've just been some other artifact introduced during the hours of messing with the code. Back to the code-mine. Richard -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFCBwrgrGisBEHG6TARAn57AJ9wnws/1GxZ7iMWUlqeWI8/8YNi9QCghqu9 pWtsieWTzWArDN1jZuam1L8= =BwJH -----END PGP SIGNATURE-----
participants (2)
-
Richard Jones -
Stefan H. Holek