2.7 branch: attribute permission problems
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 [might dupe - sent the first copy of this from the wrong address, sorry!] I've just upgraded to use the bleeding-edge 2-7 branch (from 2.7.2, running in py 2.3.3) and I've started getting permission problems with attributes. The cause appears to be acquired attributes. With VerboseSecurity installed (note: behaviour not dependent on VS - I checked), I get told: Error Type: Unauthorized Error Value: The container has no security assertions. Access to 'secure_url' of (CG Conference Proposals proposals at 0x41387b40) denied. The "secure_url" attribute is defined at a much higher object, where we have a declaration including: security.setDefaultAccess({'secure_url': 1}) 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. 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 :) Richard -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFBR5hnrGisBEHG6TARAuucAJ42D8pU6kuPQ+mBwadqJq8uQbG12gCggN2u AzBBhs5eCekTdl6bYtyBrCk= =aUXn -----END PGP SIGNATURE-----
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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wed, 15 Sep 2004 12:15 pm, Chris McDonough wrote:
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?
Yep, that's the situation. It appears to look for the security assertions for "secure_url" on A instead of B. Note that "secure_url" is an attribute of B. Richard -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFBR6aJrGisBEHG6TARAgw+AJsFrHNQ7cSs+d4baUjcp6WMznJ83wCfXtVi anfvnB2Gi2xUwQWLVTfoAUk= =BHr1 -----END PGP SIGNATURE-----
Yep, that's the situation. It appears to look for the security assertions for "secure_url" on A instead of B. Note that "secure_url" is an attribute of B.
Yup. IOW, it looks like it used to find the first "secure_url" it could access and return that, even if there were other acquirable "secure_url" attrs before that one in the acquisition path. I'm sure the fact that it ignores any intermediate (but inaccessible) "secure_url" attrs is what Tres meant by DWIM. But I'm not sure that he intended for the patch to have this effect. I'm not even sure why it does have this effect; the "validate" function is just too byzantine to understand without taking it through the debugger. - C
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wed, 15 Sep 2004 12:36 pm, Chris McDonough wrote:
Yep, that's the situation. It appears to look for the security assertions for "secure_url" on A instead of B. Note that "secure_url" is an attribute of B.
Yup. IOW, it looks like it used to find the first "secure_url" it could access and return that, even if there were other acquirable "secure_url" attrs before that one in the acquisition path. I'm sure the fact that it ignores any intermediate (but inaccessible) "secure_url" attrs is what Tres meant by DWIM.
I *think* you're implying that there might be more than one secure_url attribute in the acquisition path? If so, that's not the case. There is only one, and it's on B. Or perhaps what you're saying is that in the pre-patch days, if there *was* an attribute on A, then validate() would do the Wrong Thing, or something otherwise bad would happen. I'm a little confused about why I'm the only person seeing this, BTW...
But I'm not sure that he intended for the patch to have this effect. I'm not even sure why it does have this effect; the "validate" function is just too byzantine to understand without taking it through the debugger.
You can say that again. My head hurts every time I need to look into validate() and friends ;) Richard -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFBR63CrGisBEHG6TARAs2WAJwK2fKlW5KQvPj/LGDT2sGY93q46gCdFRN0 ZsQlTMxX/PHuRN4XZ9Uxq9I= =2gJy -----END PGP SIGNATURE-----
On Tue, 2004-09-14 at 22:49, Richard Jones wrote:
Yup. IOW, it looks like it used to find the first "secure_url" it could access and return that, even if there were other acquirable "secure_url" attrs before that one in the acquisition path. I'm sure the fact that it ignores any intermediate (but inaccessible) "secure_url" attrs is what Tres meant by DWIM.
I *think* you're implying that there might be more than one secure_url attribute in the acquisition path? If so, that's not the case. There is only one, and it's on B.
Yup.
Or perhaps what you're saying is that in the pre-patch days, if there *was* an attribute on A, then validate() would do the Wrong Thing, or something otherwise bad would happen.
In the pre-patch days, guarded getattr did "validate" on basically every object in the acquisition chain and returned the first attribute that the user could access in that chain. Now guarded_getattr relies on whatever "validate" does when it receives the top-level object and doesn't try to do anything fancy to find an accessible attribute. I'd just stick the code back in there for now and we'll see what Tres says.
I'm a little confused about why I'm the only person seeing this, BTW...
Me too. It'd be nice if "A" had a secure_url attribute, then it might even be explicable. I don't have the patience at the moment to pdb through validate, so I can only guess why it is actually happening. ;-)
But I'm not sure that he intended for the patch to have this effect. I'm not even sure why it does have this effect; the "validate" function is just too byzantine to understand without taking it through the debugger.
You can say that again. My head hurts every time I need to look into validate() and friends ;)
It could be worse, you could have found a problem in BaseRequest.traverse. ;-) - C
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wed, 15 Sep 2004 01:00 pm, Chris McDonough wrote:
I'd just stick the code back in there for now and we'll see what Tres says.
This is what I've done to speed up my testing, rather than fixing all the places stuff is broken. I'll be testing for the rest of today, and if all goes well I'll get the 2.7 branch installed tomorrow. Thanks for all your help and support, Chris! Richard -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFBR7vhrGisBEHG6TARAi59AKCAXYGiOWm5vVek8YJrWeKls0UhdACfXGFq D3QaJdBpgpNAx7WYLpleiOA= =I274 -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 15/09/2004, at 1:00 PM, Chris McDonough wrote:
I'd just stick the code back in there for now and we'll see what Tres says.
No word from Tres, 2.7 branch release coming up... Richard -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (Darwin) iD8DBQFBT34orGisBEHG6TARAsnUAJ9AFw/zOZ5gpXJIKNR837OcGiv62ACfRzXU +4k+jkEV0WFzU7RuiMXnScE= =mH5+ -----END PGP SIGNATURE-----
Tres is in Austria at the Plone conference. Don't expect any quick turnaround... jens On Sep 21, 2004, at 3:04, Richard Jones wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 15/09/2004, at 1:00 PM, Chris McDonough wrote:
I'd just stick the code back in there for now and we'll see what Tres says.
No word from Tres, 2.7 branch release coming up...
Richard -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (Darwin)
iD8DBQFBT34orGisBEHG6TARAsnUAJ9AFw/zOZ5gpXJIKNR837OcGiv62ACfRzXU +4k+jkEV0WFzU7RuiMXnScE= =mH5+ -----END PGP SIGNATURE-----
_______________________________________________ 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 )
--------------- Jens Vagelpohl jens@zetwork.com Software Engineer Zope - done medium rare Zetwork GmbH http://www.zetwork.com/
Richard Jones wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 15/09/2004, at 1:00 PM, Chris McDonough wrote:
I'd just stick the code back in there for now and we'll see what Tres says.
No word from Tres, 2.7 branch release coming up...
Tres has been on the road for ten days, with no connectivity for the last couple. I do want to review the patch -- maybe I can get together with ChrisM here in Vienna to look at it. Tres. -- =============================================================== Tres Seaver tseaver@zope.com Zope Corporation "Zope Dealers" http://www.zope.com
Richard, Would you be able to write a short test case that demonstrates the failure mode that you're seeing in your existing code? It would be nice to understand the failure before blindly reenabling the old behavior because it really is DWIM. Thanks! - C On Tue, 2004-09-14 at 21:18, Richard Jones wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
[might dupe - sent the first copy of this from the wrong address, sorry!]
I've just upgraded to use the bleeding-edge 2-7 branch (from 2.7.2, running in py 2.3.3) and I've started getting permission problems with attributes. The cause appears to be acquired attributes. With VerboseSecurity installed (note: behaviour not dependent on VS - I checked), I get told:
Error Type: Unauthorized Error Value: The container has no security assertions. Access to 'secure_url' of (CG Conference Proposals proposals at 0x41387b40) denied.
The "secure_url" attribute is defined at a much higher object, where we have a declaration including:
security.setDefaultAccess({'secure_url': 1})
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.
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 :)
Richard -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux)
iD8DBQFBR5hnrGisBEHG6TARAuucAJ42D8pU6kuPQ+mBwadqJq8uQbG12gCggN2u AzBBhs5eCekTdl6bYtyBrCk= =aUXn -----END PGP SIGNATURE----- _______________________________________________ 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 )
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wed, 22 Sep 2004 12:40 am, Chris McDonough wrote:
Would you be able to write a short test case that demonstrates the failure mode that you're seeing in your existing code? It would be nice to understand the failure before blindly reenabling the old behavior because it really is DWIM.
Yes, and I have to try to produce a test case that shows up the ComputedAttribute issues I've been having too. I'm flat out at work (now that I'm no longer spending most of my time fixing ZODB corruptions and their fallout, I have a huge backlog of work to catch up on ;) Richard -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFBUVJorGisBEHG6TARAkPXAJ9ZPiTqzqwWT9ziPsobk0PzMm1eRACbB6ah gHxjiD/alPSmQiTzENXJCeA= =Ly80 -----END PGP SIGNATURE-----
Alright, well, in the meantime, I think we're going to release the beta with the aq_acquire DWIM removed and if it causes other folks problems we'll be able to tell from folks using the beta.... On Wed, 2004-09-22 at 06:22, Richard Jones wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Wed, 22 Sep 2004 12:40 am, Chris McDonough wrote:
Would you be able to write a short test case that demonstrates the failure mode that you're seeing in your existing code? It would be nice to understand the failure before blindly reenabling the old behavior because it really is DWIM.
Yes, and I have to try to produce a test case that shows up the ComputedAttribute issues I've been having too. I'm flat out at work (now that I'm no longer spending most of my time fixing ZODB corruptions and their fallout, I have a huge backlog of work to catch up on ;)
Richard -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux)
iD8DBQFBUVJorGisBEHG6TARAkPXAJ9ZPiTqzqwWT9ziPsobk0PzMm1eRACbB6ah gHxjiD/alPSmQiTzENXJCeA= =Ly80 -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wed, 22 Sep 2004 11:14 pm, Chris McDonough wrote:
Alright, well, in the meantime, I think we're going to release the beta with the aq_acquire DWIM removed and if it causes other folks problems we'll be able to tell from folks using the beta....
Yep, fair enough. Richard -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFBUffArGisBEHG6TARAni2AJ91sSfjNfzMQcEoG4U6zeiAc7GJ9wCeMzY4 10Ol8uSnIojUvCWbl4c9Mqg= =cWQn -----END PGP SIGNATURE-----
participants (4)
-
Chris McDonough -
Jens Vagelpohl -
Richard Jones -
Tres Seaver