June 2006 - Zope-Dev

Traversal issue which affects Five
by Alec Mitchell 21 Aug '06

21 Aug '06

Hi all, It seems that the way OFS.Traversable.restrictedTraverse() handles security checking on objects with __bobo_traverse__ methods is considerably different from the way it normally checks security. The result is that traversal cannot obtain attributes using acquisition from objects that are marked <five:traversable>. In the normal case, security is checked using guarded_getattr, which gets an attribute and checks the permissions on the retrieved object in its original context. For __bobo_traverse__methods which return simple properties (say strings), it is impossible to determine the container from which the returned attribute originates, so unless the attribute was not acquired, an Unauthorized error will always be raised. Objects that are Five Traversable always have __bobo_traverse__ methods which attempt to mimic normal traversal, which effectively means that the security checks end up preventing acquisition of simple properties using traversal from ever working on these objects (say using a TAL path expression 'context/attribute' which you expect to be acquired). Unfortunately, because Five has no control over the security checks done during traversal, this cannot be fixed directly in Five. However, IMHO fixing this makes sense for Zope itself, provided there aren't any undesirable consequences. I propose that if the validation of a __bobo_traverse result raises Unauthorized, that we make one last check to see if the result o 'guarded_getattr(obj, name)' is identical to the result of the __bobo_traverse__ call and allow it if that's the case. Here is my proposed patch against Zope 2.9 trunk: --- Traversable.py (revision 66323) +++ Traversable.py (working copy) @@ -201,9 +201,18 @@ else: # Can't determine container container = _none - if not securityManager.validate( - obj, container, name, next): - raise Unauthorized, name + try: + if not securityManager.validate( + obj, container, name, next): + raise Unauthorized, name + except Unauthorized: + # If next is a simple unwrapped property, it's + # parentage is indeterminate, but it may have been + # acquired safely. In this case validate will raise + # an error, and we can check that our value was + # acquired safely. + if guarded_getattr(obj, name, marker) is not next: + raise Unauthorized, name else: if restricted: next = guarded_getattr(obj, name, marker) At the moment Plone 2.5 is really struggling with this issue, and it would be wonderful if a fix for this could go into Zope 2.8 and 2.9 soon. I'm happy to write tests for this, I just want to make sure that I'm not proposing something really wrong/inappropriate here. Generally, the validate() call should return a True or False value, so this change should have little performance impact except in the case where 'container == _none' and validate would otherwise raise a very unhelpful unauthorized error. Your feedback is much appreciated. Alec Mitchell

6 16

Re: [Checkins] SVN: Zope/branches/2.9/lib/python/ Replace bulk of uses of 'zLOG' with equivalent Python 'logging' module usage.
by Stefan H. Holek 11 Jul '06

11 Jul '06

This, BTW, breaks CMF 1.5 on Zope 2.9. Not sure I/you should care though ;-) Traceback (most recent call last): File "/home/stefan/autotest/temp/python24-zope29-cmf15/Products/ CMFActionIcons/__init__.py", line 19, in ? from Products.CMFCore.DirectoryView import registerDirectory File "/home/stefan/autotest/temp/python24-zope29-cmf15/Products/ CMFCore/__init__.py", line 21, in ? import MembershipTool, WorkflowTool, CatalogTool, DiscussionTool File "/home/stefan/autotest/temp/python24-zope29-cmf15/Products/ CMFCore/CatalogTool.py", line 23, in ? from Products.ZCatalog.ZCatalog import LOG ImportError: cannot import name LOG On 25. Jun 2006, at 00:45, Tres Seaver wrote: > Modified: Zope/branches/2.9/lib/python/Products/ZCatalog/ZCatalog.py > =================================================================== > --- Zope/branches/2.9/lib/python/Products/ZCatalog/ZCatalog.py > 2006-06-24 21:59:59 UTC (rev 68834) > +++ Zope/branches/2.9/lib/python/Products/ZCatalog/ZCatalog.py > 2006-06-24 22:45:20 UTC (rev 68835) > @@ -37,7 +37,6 @@ > import PluggableIndexInterface > from Products.PluginIndexes.interfaces import IPluggableIndex > from Products.PluginIndexes.TextIndex import Splitter > -from zLOG import LOG > from zope.interface import implements -- Anything that, in happening, causes something else to happen, causes something else to happen. --Douglas Adams

5 5

Proposal: Scrap zpkg for Zope2 releases
by Tres Seaver 06 Jul '06

06 Jul '06

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I worked last night with folks from the Fedora Extras project who were trying to package Zope 2.9.3 for FC5+. Because they were working from the release tarball, generated by 'zpkg', much of my knowledge about how the build process works (or doesn't) was invalid: - The Makefile generated by 'zpkg' does not have bugfixes / features which have been made to the 'Makefile' created by 'configure' in a checkout. - The 'install.py' script has subtly-different semantics from the 'setup.py' script in the checkout. In particular, it was hard to figure out how to get the installed libraries correct for the x86_64 package. - We have had a bunch of bugs since 2.9 related to the 'zpkg'-based build, some related to lost features and other to various kinds of breakage (see #1967, #1968, #1996, #2030, #2081, #2082, #2083, #2121). - Working inside the 'zpkg'-generated tarball is *very* confusing, even for experienced Zope developers: "Where is the source?" is a frequent cry in such cases. All of this is due to the fact that none of the maintainers of Zope2 is also a conusmer of the zpkg-gnereated releases; those consumers are the downstream packagers and sysadmins who have no idea how to work in that setup, and who can't even (easily) get help on it from the Zope developer community. I believe that the extra flexibility which zpkg is intended to provide (dependency-based subset distributions, primarily) would be better served by moving Zope to use eggs, and that we should thus retire zpkg as the means for building Zope2 releases. Instead, we should recreate the version of the 'inst' stuff removed in the 2.9 beta cycle, and update it for any changes to the tree made since then. I volunteer to do the work, assuming the community concurs. Tres. - -- =================================================================== Tres Seaver +1 202-558-7113 tseaver(a)palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEmqrH+gerLs4ltQ4RApF2AKDTWq8XqY4OCuj5BpPZ3omCpnzEtwCghPnO nZ8S8NqTC1oZx8o3KVVJxBo= =4qXe -----END PGP SIGNATURE-----

11 27

the zope, eggs and the testrunner
by whit 30 Jun '06

30 Jun '06

I've been developping some packages using zope.testing and the testrunner that ships with zope2.10. Yesterday, I packaged these using fairly standard python/egg pattern. one package is pure python, the other a zope2/zope3 hybrid. now I have two large PITAs: 1. in general, this would suck alot less if easyinstall would recognize I already have package x, y, and z on my PYTHONPATH, rather than helpfully installing incompatible ones or erroring out when it can't resolve zope dependency x from the ether. Doesn't seem to be a --stop-sucking flag that I can find. removing all the zopeish things like zope.interface and zope.testing solves this problem for the pure python package (but sort of make things like testing interfaces out of the question). 2. zopectl test doesn't see my tests with said packages installed in develop mode or as eggs (assorted --path etc options don't seem to help). Running the tests via python setup.py test only works when I unflag the testing dependency of zope.testing. anyone been down this rabbit hole? have any suggestions? resources? -w -- | david "whit" morriss | | contact :: http://public.xdi.org/=whit "If you don't know where you are, you don't know anything at all" Dr. Edgar Spencer, Ph.D., 1995 "I like to write code like other ppl like to tune their cars or 10kW hifi equipment..." Christian Heimes, 2004

1 0

Can logreopen restarts Zope ?
by Julien Anguenot 30 Jun '06

30 Jun '06

Hi there, I observed a strange behavior yesterday night on one of our ZEO cluster. We got 4 ZEO servers on the cluster. We are rotating the ZEO logs once every night using logreopen. Until now, we didn't observe any misbehavior. Meaning, logs were rotated and then reopened ok on the four of them every night since couple of weeks now. Yesterday night, we were having a long nightly running process (several hours) on one of the ZEO node. (Around 500 Mo logs on this one). The reopen occurred while the Zope server was still working. The reopen went ok but it restarted the Zope server at the same time which of course stopped the actual running operation of ours. Did someone experienced this ? Any feedbacks appreciated. Thanks. J. P.S : Python-2.4.2, Zope-2.9.0 -- Julien Anguenot | Nuxeo R&D (Paris, France) Open Source ECM - www.nuxeo.com CPS Platform - http://www.cps-project.org Mobile: +33 (0) 6 72 57 57 66

4 6

Setting up the Zope Management Organization
by Jim Fulton 30 Jun '06

30 Jun '06

One of the most urgent tasks for the Zope Foundation is to set up the Zope Management Organization (ZMO) as described in Section 7 of the bylaws: http://www.zope.org/DevHome/Foundation/ZopeFoundationByLaws.pdf In particular, we need to come up with a Zope Development Process, ZDP, identify initial "projects" and form project leadership for each project. It is possible that the by laws specify too much bureaucracy for the ZMO, however, rather than spending time trying to change this, I suggest we try to work within it by creating a simple and flexible ZDP and doing what we can to manage the ZMO in a lightweight way. In the first meeting, the Board formed a committee to organize the ZMO with Martijn Faassen and me as Board representatives. (I hope that the minutes will be published to the Foundation mailing list soon.) I'm am looking for volunteers to serve on this committee. Also, for those of you who will be at EuroPython, this will be an excellent opportunity to brainstorm ideas. Note that there will be an informal Dinner on Sunday night: http://mail.zope.org/pipermail/foundation/2006-June/000107.html and a panel discussion on the 4th: http://indico.cern.ch/contributionDisplay.py? contribId=96&sessionId=9&confId=44 I expect that there will be lots of other opportunities to get together and work on creating an effective Foundation. If you want to be involved in the foundation, make sure to subscribe to the founadtion mailing list at: http://mail.zope.org/mailman/listinfo/foundation Jim -- Jim Fulton mailto:jim@zope.com Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org _______________________________________________ Foundation-committers mailing list Foundation-committers(a)zope.org http://mail.zope.org/mailman/listinfo/foundation-committers

1 0

zasync/xmlrpclib problem
by Florent Guillaume 29 Jun '06

29 Jun '06

Gary, When zasync is used on something that calls a xmlrpclib method s.foo.bar() (using s = xmlrpclib.ServerProxy(...)) and this xmlrpc call fails, it seems that cleanFailure at some point calls repr (s.foo.bar) and this makes a spurious xmlrpc call (because of the dumb _Method class of xmlrpclib which has a __getattr__ but no __repr__). I had to monkey patch xmlrpclib thus, you could probably include it in zasync: import xmlrpclib def xmlrpc_method_repr(self): return '<xmlrpc._Method %s>' % self._Method__name xmlrpclib._Method.__repr__ = xmlrpc_method_repr Florent -- Florent Guillaume, Nuxeo (Paris, France) Director of R&D +33 1 40 33 71 59 http://nuxeo.com fg(a)nuxeo.com

1 0

Re: [Checkins] SVN: Zope/branches/2.10/ OFS Image: Image and File now both support simple unicode objects for data (they function the same as strings for data).
by Florent Guillaume 28 Jun '06

28 Jun '06

Has this change been discussed? I don't agree with it. Unicode strings aren't byte strings. File and Image should only work with byte strings. Code dealing with them should always know and assume that they use str. Anything using unicode with them is broken or has done insufficient input validation. Please revert, unless you can convince me otherwise. Florent On 28 Jun 2006, at 13:24, Rocky Burt wrote: > Log message for revision 68876: > OFS Image: Image and File now both support simple unicode objects > for data (they function the same as strings for data). > > Changed: > U Zope/branches/2.10/doc/CHANGES.txt > U Zope/branches/2.10/lib/python/OFS/Image.py > U Zope/branches/2.10/lib/python/OFS/tests/testFileAndImage.py > > -=- > Modified: Zope/branches/2.10/doc/CHANGES.txt > =================================================================== > --- Zope/branches/2.10/doc/CHANGES.txt 2006-06-28 11:20:16 UTC (rev > 68875) > +++ Zope/branches/2.10/doc/CHANGES.txt 2006-06-28 11:24:05 UTC (rev > 68876) > @@ -18,6 +18,9 @@ > > Bugs Fixed > > + - OFS Image: Image and File now both support simple unicode > objects > + for data (they function the same as strings for data). > + > - OFS Application: Updated deprecation warnings. > Support for '__ac_permissions__' and 'meta_types' will be > removed in > Zope 2.11, 'methods' support might remain longer. > > Modified: Zope/branches/2.10/lib/python/OFS/Image.py > =================================================================== > --- Zope/branches/2.10/lib/python/OFS/Image.py 2006-06-28 11:20:16 > UTC (rev 68875) > +++ Zope/branches/2.10/lib/python/OFS/Image.py 2006-06-28 11:24:05 > UTC (rev 68876) > @@ -43,7 +43,6 @@ > from cgi import escape > import transaction > > -StringType=type('') > manage_addFileForm=DTMLFile('dtml/imageAdd', globals > (),Kind='File',kind='file') > def manage_addFile(self,id,file='',title='',precondition='', > content_type='', > REQUEST=None): > @@ -231,7 +230,7 @@ > RESPONSE.setStatus(206) # Partial content > > data = self.data > - if type(data) is StringType: > + if isinstance(data, basestring): > RESPONSE.write(data[start:end]) > return True > > @@ -302,7 +301,7 @@ > 'Content-Range: bytes %d-%d/%d\r\n\r > \n' % ( > start, end - 1, self.size)) > > - if type(data) is StringType: > + if isinstance(data, basestring): > RESPONSE.write(data[start:end]) > > else: > @@ -401,7 +400,7 @@ > self.ZCacheable_set(None) > > data=self.data > - if type(data) is type(''): > + if isinstance(data, basestring): > RESPONSE.setBase(None) > return data > > @@ -481,7 +480,7 @@ > if headers and headers.has_key('content-type'): > content_type=headers['content-type'] > else: > - if type(body) is not type(''): body=body.data > + if not isinstance(body, basestring): body=body.data > content_type, enc=guess_content_type( > getattr(file, 'filename',id), body, content_type) > return content_type > @@ -490,7 +489,7 @@ > > n=1 << 16 > > - if type(file) is StringType: > + if isinstance(file, basestring): > size=len(file) > if size < n: return file, size > # Big string: cut it into smaller chunks > @@ -617,7 +616,7 @@ > return result > > data = self.data > - if type(data) is type(''): > + if isinstance(data, basestring): > RESPONSE.setBase(None) > return data > > > Modified: Zope/branches/2.10/lib/python/OFS/tests/testFileAndImage.py > =================================================================== > --- Zope/branches/2.10/lib/python/OFS/tests/testFileAndImage.py > 2006-06-28 11:20:16 UTC (rev 68875) > +++ Zope/branches/2.10/lib/python/OFS/tests/testFileAndImage.py > 2006-06-28 11:24:05 UTC (rev 68876) > @@ -252,7 +252,15 @@ > verifyClass(HTTPRangeInterface, File) > verifyClass(WriteLockInterface, File) > > - > + def testUnicodeWithIndexHtml(self): > + # Introduced to help test the fact that Image.py has been > + # changed to be lenient towards any basestring type, not > just str > + > + val = u'some unicode string here' > + self.file.manage_edit('foobar', 'text/plain', filedata=val) > + s = self.file.index_html(self.app.REQUEST, > self.app.REQUEST.RESPONSE) > + self.assertEquals(s, val) > + > class ImageTests(FileTests): > data = open(filedata, 'rb').read() > content_type = 'image/gif' > @@ -285,7 +293,6 @@ > > verifyClass(WriteLockInterface, Image) > > - > def test_suite(): > return unittest.TestSuite(( > unittest.makeSuite(FileTests), > > _______________________________________________ > Checkins mailing list > Checkins(a)zope.org > http://mail.zope.org/mailman/listinfo/checkins -- Florent Guillaume, Nuxeo (Paris, France) Director of R&D +33 1 40 33 71 59 http://nuxeo.com fg(a)nuxeo.com

4 6

DomainAuthenticationMode with Sockets
by Juan Javier Carrera Obrero 27 Jun '06

27 Jun '06

Hi, I am trying to access by means of "sockets" to a folder that contains a acl_user folder with enabled DomainAuthenticationMode (domain_auth_mode=1) from a enabled IP in the domain (I have created a user specifying a domain with this IP and I have left the password for this user blank). It runs successfully HTTP via but it does not run Socket via requering authentication although I am in the domain. When I use HTTP via the Authenticated_User is Ok, however when I user Socket via the Authenticated_User is "Anonymous User". I am using "(Zope 2.7.5-final, python 2.3.5, linux2". Anybody help me about it? Does the DomainAuthenticationMode of a acl_user folder runs successfully via Socket ? Thanks !

2 2

OFS.Application deprecations for Zope 2.10
by Florent Guillaume 27 Jun '06

27 Jun '06

OFS.Application has a few deprecations warnings that were supposed to go away in Zope 2.10: __init__.py of %s has a long deprecated '__ac_permissions__' attribute. __init__.py of %s has a long deprecated 'meta_types attribute. __init__.py of %s has a long deprecated 'methods' attribute. Shall we remove them now? Note that ExternalEditors 0.9.1 for instance still used 'methods' but that's its own damn fault. Florent -- Florent Guillaume, Nuxeo (Paris, France) Director of R&D +33 1 40 33 71 59 http://nuxeo.com fg(a)nuxeo.com

18 148