[ZODB-Dev] Bug (?) in zope/publisher/publish.py:unwrapMethod

2011-01-25 Thread Vincent Pelletier
Hi.

In publish.py[1], unwrapMethod tried to find what can be used to publish an 
object. In a site, I had someone create a very-badly-named func_code 
external method in a place accessible by acquisition from every page on the 
site (this bad by itself, and I corrected it already). This caused 
unwrapMethod to think it can use any object directly for publishing, because 
of:

elif getattr(unwrapped, 'func_code', None) is not None:
break

and unwrapped is still in an acquisition context.

Shouldn't the checks be done on unwrapped (from acquisition context) objects 
instead, to prevent such stupid mistake to have such a wide impact.

I have the intuition that this could even be a security problem, allowing an 
unexpected object to be called instead of another, but I cannot come out with 
an example.

Do you think there is anything to fix in zope.publisher ? If so, I'll open a 
bug.

[1] 
http://svn.zope.org/zope.publisher/trunk/src/zope/publisher/publish.py?view=markup

Regards,
-- 
Vincent Pelletier
___
For more information about ZODB, see the ZODB Wiki:
http://www.zope.org/Wikis/ZODB/

ZODB-Dev mailing list  -  ZODB-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zodb-dev


Re: [ZODB-Dev] Bug (?) in zope/publisher/publish.py:unwrapMethod

2011-01-25 Thread Tres Seaver
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 01/25/2011 12:19 PM, Vincent Pelletier wrote:
 Hi.
 
 In publish.py[1], unwrapMethod tried to find what can be used to publish an 
 object. In a site, I had someone create a very-badly-named func_code 
 external method in a place accessible by acquisition from every page on the 
 site (this bad by itself, and I corrected it already). This caused 
 unwrapMethod to think it can use any object directly for publishing, because 
 of:
 
 elif getattr(unwrapped, 'func_code', None) is not None:
 break
 
 and unwrapped is still in an acquisition context.
 
 Shouldn't the checks be done on unwrapped (from acquisition context) objects 
 instead, to prevent such stupid mistake to have such a wide impact.
 
 I have the intuition that this could even be a security problem, allowing an 
 unexpected object to be called instead of another, but I cannot come out with 
 an example.
 
 Do you think there is anything to fix in zope.publisher ? If so, I'll open a 
 bug.
 
 [1] 
 http://svn.zope.org/zope.publisher/trunk/src/zope/publisher/publish.py?view=markup

The 'zope.publisher' package doesn't know anything about
acquisition-wrapped objects:  fixing this issue there would require
adding either a dependency on 'Acquisition' (a bad idea, I think) or
else adding logic like the 'im_func' bit which peeled away 'aq_self'
until all wrappers were gone (using knowleged of Acquisition's API /
semantics without importing it).

The Zope2-specific version of 'mapply()' (in 'ZPublisher.mapply') is the
right place to fix this issue, if it is to be fixed:  it could ensure
that the acquisition wrapper was stripped away before calling
'unwrapMethod()'.

P.S. This issue is off-topic for the ZODB list:  I have cross-posted
 to 'zope-dev':  please follow up there.


Tres.
- -- 
===
Tres Seaver  +1 540-429-0999  tsea...@palladion.com
Palladion Software   Excellence by Designhttp://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk0/H5sACgkQ+gerLs4ltQ4jdQCgzI+yNAuaX9cqPg77FLHxbzUG
abwAn0BJoQ5ImlTrocRMY3KT3M2royOz
=WSyR
-END PGP SIGNATURE-

___
For more information about ZODB, see the ZODB Wiki:
http://www.zope.org/Wikis/ZODB/

ZODB-Dev mailing list  -  ZODB-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zodb-dev