- Zope-Dev - Zope lists

cPickleCache endless loop...
by Mario Lorenz 28 Jan '04

28 Jan '04

Hello, we have spent most of the day tracking down obscure hangs of Zope (2.6.4rc1) under python2.1.3 on a RHEL3 machine. The problem seems to be a logic flaw somewhere related to the cPickleCache, when using a destructor in a Zope object that accesses itself. In our case(shortened to the offending line): def __del__(self): print "About to destroy: ", self.id What seems to happen is that the "self.id" access causes the object to be cached again, causing scan_gc_items() to run in circles. Any ideas on how to best fix this? Mario -- Mario Lorenz EMail: Mario.Lorenz(a)km3.de Tel: 03774 6625-78 Technik Netze Handy: 0160 3151600 km3 teledienst GmbH Fax: 03774 6625-79

7 12

ConflictError in BTreeFolder2
by Florent Guillaume 27 Jan '04

27 Jan '04

FYI: I've fixed BTreeFolder2 to properly re-raise ConflictError in _delObject and not swallow it during beforeDelete cleanups. This is the same fix that was done in ObjectManager. Florent -- Florent Guillaume, Nuxeo (Paris, France) +33 1 40 33 79 87 http://nuxeo.com mailto:fg@nuxeo.com

3 3

fdrake's fix for brian's fix for bug 1203 needs to be applied in other branches
by Leonardo Rochael Almeida 27 Jan '04

27 Jan '04

Hi, There's a recent entry in the 2.6 branch from fred stating: types don't have a guaranteed truth value, so check that it isn't None the diff is here: http://cvs.zope.org/Zope/lib/python/ZTUtils/Zope.py.diff?r1=1.10.6.3&r2=1.1… This same fix needs to be applied to at least the 2.7 branch and HEAD, probaly other branches too, but I haven't checked. Should I file a bug for this? Cheers, Leo -- Ideas don't stay in some minds very long because they don't like solitary confinement.

3 4

Re: [Zope-dev] cPickleCache endless loop...
by Paul Winkler 27 Jan '04

27 Jan '04

On Mon, Jan 26, 2004 at 08:59:36AM +0000, Chris Withers wrote: > Paul Winkler wrote: > > >On Fri, Jan 23, 2004 at 12:08:27PM -0500, Tim Peters wrote: > > > >>>def __del__(self): > >>> print "About to destroy: ", self.id > > > >I don't know what your intention is there, but fwiw, if > >what you're *really* interested in is the object being > >marked for deletion in the ZODB, you can use: > > I'm pretty sure that only works in Zope, so? the O.P. was about zope, and this IS the zope-dev list... > and even then, when the > ObjectManager stuff comes into play ;-) true enough. -- Paul Winkler http://www.slinkp.com Look! Up in the sky! It's THE FASCIST! (random hero from isometric.spaceninja.com)

2 1

2.6.4.c1 still problem with security
by robert rottermann 26 Jan '04

26 Jan '04

Hi there, I am using zope from cvs Zope-2_6-branch. I still get the following assertion in a DCWorkflow which worked flawlessly in 2.6.2 Thanks for any pointers Robert Traceback (innermost last): Module ZPublisher.Publish, line 98, in publish Module ZPublisher.mapply, line 88, in mapply Module ZPublisher.Publish, line 39, in call_object Module Products.CMFCore.FSPythonScript, line 92, in __call__ Module Shared.DC.Scripts.Bindings, line 261, in __call__ Module Shared.DC.Scripts.Bindings, line 292, in _bindAndExec Module Products.CMFCore.FSPythonScript, line 126, in _exec - __traceback_info__: ({'traverse_subpath': [], 'container': <PloneSite instance at 8bbed10>, 'context': <PloneFolder instance at 96fb608>, 'script': <FSPythonScript at /zehnder/zehnder/createObject used for /zehnder/zehnder/tasklist/Task.2004-01-19.3020/Attachments>}, (None, 'File', None), {}, (None, None, None)) Module None, line 12, in createObject Module Products.CMFCore.PortalFolder, line 362, in invokeFactory Module Products.CMFCore.TypesTool, line 824, in constructContent Module Products.CMFCore.TypesTool, line 516, in constructInstance Module Products.CMFCore.TypesTool, line 420, in _finishConstruction Module Products.CMFCore.CMFCatalogAware, line 101, in notifyWorkflowCreated Module Products.CMFPlone.WorkflowTool, line 26, in notifyCreated Module Products.CMFCore.WorkflowTool, line 362, in notifyCreated Module Products.DCWorkflow.DCWorkflow, line 367, in notifyCreated Module Products.DCWorkflow.DCWorkflow, line 440, in _changeStateOf Module Products.DCWorkflow.DCWorkflow, line 543, in _executeTransition Module Shared.DC.Scripts.Bindings, line 261, in __call__ Module Shared.DC.Scripts.Bindings, line 290, in _bindAndExec Module Shared.DC.Scripts.Bindings, line 1, in ? Module Shared.DC.Scripts.Bindings, line 224, in _getContext Unauthorized: You are not allowed to access in this context

2 3

ZODB load state error
by Thyb 26 Jan '04

26 Jan '04

Hi, I just found this in my Zope log file. After this error the Zope system stopped. No wonder, but certainly not because of physical memory error. What could be the problem? My config is: AiX 5.2 Python 2.3.2 Zope 2.7.0-b3 Apache 1.3.26 The error message: 2004-01-25T02:55:21 ERROR(200) ZODB Couldn't load state for 0000000000003ef2 Traceback (most recent call last): File "/opt/freeware/zope/lib/python/ZODB/Connection.py", line 564, in setstate self._set_ghost_state(obj, p) File "/opt/freeware/zope/lib/python/ZODB/Connection.py", line 603, in _set_ghost_state state = unpickler.load() MemoryError Can someone please help me... Tibor Tolgyesi

4 3

ZODB 3.3 in Zope 3 status
by Jim Fulton 26 Jan '04

26 Jan '04

Fred Drake and I have been working on getting Zope 3 working with ZODB 3.3. See: http://zope.org/Wikis/ZODB/PersistentCodeImplementationPlan (which is part of the Zope 2,8 plan) We are currently working on milestone 2. I *hope* to get this done early this week. When we think everything is working, and all the tests pass, we'll merge the changes into the head. From that point on, both Zope 2 and Zope 3 will share: - Common ZODB (3.3) - Common interface package This is a big enough change that it's bound to make things interesting for Both Zope 2 and Zope 3, although the Zope 2 head is already in a rather unstable state. Some additional notes: - We will provide a script for converting ZODB 4 file storages to the ZODB 3 format. All Zope 3 users that wish to continue using the head will need to run this script. - We will cause some minor temporary breakage on the Zope 2 head. Specifically, broken object support will partially go away until we do milestone 3. Note that ZClasses are already broken on the Zope head. There were no tests to detect this when I merged the ExtensionClass rewrite and ZODB 3.3. 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

1 0

Different code layout for "Persistence" between various Zope versions was: RE: [Zope] Can not import PersistentMapping)
by Dieter Maurer 25 Jan '04

25 Jan '04

Sean wrote at 2004-1-24 11:12 -0500: > ... >Looking at the ZOPE 2.6.2 Source on the Windows machine, I see code for >modules: Persistence.PersistentMapping, and Persistence.PersistentList > >On Linux, the Zope 2.6.1 Source has a Persistence Directory with nothing in >it. The __init__.py file says: > > ...While obviously there is nothing in this module, > the correct names are inserted by the __init__.py > in ZODB, jumpstarting the process.""" > >Actually, the __init__.py file on the windows machine says the same thing, >but there ARE in fact source files in the directory for both the >PersistentMapping and PersistentList modules - as well as some ".c" and ".h" >files - as follows: > > cPickleCache.c > cPersistence.c > cPersistence.h > PersistentList.py > PersistentMapping.py > >Would these be differences between the two versions of Zope, or are the >classes not properly setup on the Linux box, and once they are, I could >expect to see the source files that I see on the Windows box? > >Or, perhaps the way these classes were being implemented was changing >between the two releases, and I should just upgrade both machines to 2.6.4 >which is listed as the current stable release, or 2.7.0rc1. > >Recommendations? I know nothing about Windows :-) I think, I read somewhere that "PersistentMapping" and "PersistentList" should be moved out from "ZODB" to "Persistence" -- but only for Zope 2.8. I would be surprised when the Windows installation were the place where such things start... I moved your question to "mailto:zope-dev@zope.org" where there are probably more people which can answer it. -- Dieter

1 0

Zope - SecurityFocus Newsletter #232 (fwd)
by Chris Withers 24 Jan '04

24 Jan '04

Hi, Can anyone shed light on all of these? I know about some of them, but this is quite a disturbingly long list... cheers, Chris ---------- Forwarded Message ---------- Date: Tuesday, January 20, 2004 2:45 PM -0700 From: Kelly Martin <kel(a)securityfocus.com> To: sf-news(a)securityfocus.com Subject: SecurityFocus Newsletter #232 8. Zope Multiple Vulnerabilities BugTraq ID: 9400 Remote: Yes Date Published: Jan 12 2004 Relevant URL: http://www.securityfocus.com/bid/9400 Summary: Zope is an open source web application server, maintained by the Zope Project. Zope is available for Linux, Unix, and Microsoft Windows based systems. Multiple vulnerabilities have been reported to exist in the software that may allow an attacker to carry out attacks resulting from improper input validation, access validation, information disclosure, and various improper security checks on a vulnerable system. Successful exploitation of these issues may lead to cross-site scripting attacks, denial of service conditions, and other attacks. The following specific issues have been identified: The ZSearch interface has been reported to be prone to a cross-site scripting vulnerability. Successful exploitation of this issue may allow a remote attacker to carry out cross-site scripting attacks by enticing a victim user to follow a malicious link to a site hosting the software that contains embedded HTML and script code. The embedded code may be rendered in the web browser of the victim user in the security context of the site hosting the vulnerable software. A denial of service vulnerability has been identified in 'ZTUtils.SimpleTree' that may allow an attacker to cause a denial of service condition the software. This condition results from improper state handling. An access validation issue has been reported to exist in the admin "find" functions. This issue may lead to an attacker gaining access to sensitive information without proper authentication. An unspecified access validation issue has been identified in the PropertyManager 'lines' and 'tokens' properties. It has been reported that some property types are stored in a mutable data type (list) and may allow untrusted code to effect changes on the properties without proper security validation. An unspecified access validation issue may exist in the DTMLDocument objects. This issue could allow an attacker to gain access to sensitive information. Another access validation issue has been identified in DTMLMethods. It has been reported that DTMLMethods proxy rights may be incorrectly inherited when traversing to a parent object. A denial of service vulnerability has been identified in DTML tag 'dtml-tree' that may allow an attacker to cause a denial of service condition the software. An information disclosure vulnerability is reported to exist in the software. This issue may allow an attacker to disclose certain attributes via XML-RPC marshalling of class instances. An access validation issue has been reported to exist in the software that may allow unauthorized access to certain variables. This issue occurs due to improper initialization of PythonScript class security. A denial of service vulnerability exists in RESPONSE.write() that may allow an attacker to pass malicious unicode values resulting in Zserver main loop to terminate resulting in a crash or hang. An access validation issue may exist in the software due to Unpacking via function calls, variable assignment, exception variables without sufficient security check. This issue may allow an attacker to gain access to sensitive data. Another access validation issue may allow an attacker to execute a malicious script on a vulnerable system in order to gain unauthorized access to certain objects. This issue results from improper verification of variables bound to page templates and Python scripts such as 'context' and 'container'. An unspecified error has been reported to exist due to the use of min, max, enumerate, iter, and sum in untrusted code. An issue has been identified in the use of 'import as' in Python scripts that may allow an attacker to bypass security checks. Another access validation issue has been identified in the list and dictionary instance methods that may allow an attacker to gain unauthorized access to certain objects. A similar issue has also been identified in for loops, list comprehensions, and other iterations of untrusted code. Further analysis of these issues is currently underway. This BID will be separated into individual BIDs upon completion of analysis. These issues have been reported to exist in Zope versions 2.6.2 and prior and development releases 2.7.0 beta3. Other versions could be affected as well. ---------- End Forwarded Message ---------- Richard Hopkins, Information Services, Computer Centre, University of Bristol, Bristol, BS8 1UD, UK Tel +44 117 928 7859 Fax +44 117 929 1576

4 4

Re: RFC: backward compatibility of ps bindings (no resolution yet!)
by Tres Seaver 24 Jan '04

24 Jan '04

Dieter Maurer wrote: > Tres Seaver wrote at 2004-1-23 17:04 -0500: >>The script being called is invoked during a workflow transition, which >>calls the script, passing a StateChangeInfo instance; the new code >>tries to validate access to the SCI and pukes, badly, because the script >>has proxy roles, but the 'container' isn't wrapped. I *think* that we >>are seeing this issue because the new security code is tougher about >>checking access within the script. > > > But why is a "StateChangeInfo" object passed as "container" to the code > above? Just for clarity: the 'container' in play here is not the object bound as 'container' to the script; it is the argument passed to validate, which is trying to check that the script is allowed. > Up to now, I was convinced that "container" is usually (for acquisition > wrappers) the equivalent to "*.aq_inner.aq_parent" (which I would prefer > to have an "aq_container" for). > > Hopefully, we get soon (for Zope 2.9, at least) a clear specification > when "validate" is called with which arguments. It will help > everyone. > > >>I tried to work around the issue by adding a 'getPhysicalRoot' method to >>SCI, merely delegating to the underlying object; however, the script in >>my app then blows up on access to 'object' (which I may be able to fix >>as well). > > > I think, the security context should provide access to the root. > "container" and "object" can be any type of objects neither of > which may have access to the root. I am working on a fix for both parts of this; the code in question is that part of validate which is working to ensure that a script with proxy roles is not acquiring an object "above" the current user's acl_users. Tres. -- =============================================================== Tres Seaver tseaver(a)zope.com Zope Corporation "Zope Dealers" http://www.zope.com

1 0