January 2004 - Zope-Dev

Builtins on Zope 2.6.3
by Christian Theune 09 Jan '04

09 Jan '04

Hi, i have the strange feeling that somebody forgot to include the AccessControl.ZopeGuard.safe_builtins for DTML. See DT_Utils.py around line 56 and the corresponding imports as well as the definition of safe_builtins in ZopeGuard.py. Could someone verify this? Cheers, Christian -- Christian Theune, gocept gmbh & co. kg http://www.gocept.com - ct(a)gocept.com fon: 03496 3099112 fax: 03496 3099118 mobile: 0179 7808366

3 2

ANNOUNCE: Zope 2.6.3 Release and Security Update
by Brian Lloyd 09 Jan '04

09 Jan '04

Zope 2.6.3 Release and Security Update Zope 2.6.3 contains a number of security related fixes for issues resolved during a comprehensive security audit conducted in Q4 2003. You may download Zope 2.6.3 from Zope.org: http://www.zope.org/Products/Zope/2.6.3/ **Users of the VerboseSecurity add-on product for Zope please note:** some of the security-related changes in Zope 2.6.3 are incompatible with the VerboseSecurity product. Please uninstall the VerboseSecurity product before upgrading to 2.6.3 to avoid problems. It is expected that VerboseSecurity will be updated to be compatible with Zope 2.6.3 in the near future. Also note that there are binary code changes in the 2.6.3 release, making it impossible to issue an external "hotfix" to resolve these issues. CVS users should be sure to update their sites **and rebuild the C Python extensions** to ensure that all fixes are deployed. In the fourth quarter of 2003, a comprehensive evaluation of the changes to Python from version 2.1 to 2.3.3 was undertaken. This evaluation was designed to assess each change to the Python environment in terms of its potential impact on the Zope application server and Zope applications, with the goal of making Python 2.3.3 the required Python platform for Zope beginning with Zope 2.7. The evaluation was focused on assessing changes to Python in the following contexts: - Changes that would have compatibility or other effects on existing or new Zope applications - Changes that could potentially affect the Zope security architecture or change the behavior of the restricted execution environment used by Zope to run untrusted code In the course of the evaluation, very few of the Python changes in 2.3.3 directly affected the Zope security architecture or had impacts on the restricted execution model. However, a number of pre-existing potential issues were discovered and resolved in the course of the comprehensive security audit that was performed as a part of the Python upgrade evaluation. Zope 2.6.3 provides fixes for all of these issues. A description of each issue, who is affected and issue status is included below. For more information on what is new in this release, see the CHANGES.txt and HISTORY.txt files for the release: - http://www.zope.org/Products/Zope/2.6.3/CHANGES.txt - http://www.zope.org/Products/Zope/2.6.3/HISTORY.txt For more information on the available Zope releases, guidance for selecting the right distribution and installation instructions, please see: http://www.zope.org/Documentation/Misc/InstallingZope.html ISSUES RESOLVED BY Zope 2.6.3: - For loops, list comprehensions, and other iterations in untrusted code Issue Description Iteration over sequences could in some cases fail to check access to an object obtained from the sequence. Subsequent checks (such as for attributes access) of such an object would still be performed, but it should not have been possible to obtain the object in the first place. Who Is Affected? Sites that allow untrusted users to write Python Scripts, Page Templates, and DTML. Resolution This issue is resolved in Zope 2.6.3 and Zope 2.7.0 beta 4 and higher. Affected sites are strongly encouraged to update their Zope installations to prevent this issue. - List and dictionary instance methods in untrusted code Issue Description List and dictionary instance methods such as the get method of dictionary objects were not security aware and could return an object without checking access to that object. Subsequent checks (such as for attributes access) of such an object would still be performed, but it should not have been possible to obtain the object in the first place. Who Is Affected? Sites that allow untrusted users to write Python Scripts, Page Templates, and DTML. Resolution This issue is resolved in Zope 2.6.3 and Zope 2.7.0 beta 4 and higher. Affected sites are strongly encouraged to update their Zope installations to prevent this issue. - Use of import as in untrusted code Issue Description Use of "import as" in Python scripts could potentially rebind names in ways that could be used to avoid appropriate security checks. Who Is Affected? Sites that allow untrusted users to write Python Scripts, Page Templates, and DTML. Resolution This issue is resolved in Zope 2.6.3 and Zope 2.7.0 beta 4 and higher. Affected sites are strongly encouraged to update their Zope installations to prevent this issue. - Use of min, max, enumerate, iter, and sum in untrusted code Issue Description A number of newer built-ins were either unavailable in untrusted code or did not perform adequate security checking. Who Is Affected? Sites that allow untrusted users to write Python Scripts, Page Templates, and DTML. Resolution This issue is resolved in Zope 2.6.3 and Zope 2.7.0 beta 4 and higher. Affected sites are strongly encouraged to update their Zope installations to prevent this issue. - Broken binding validation in untrusted code Issue Description The variables bound to page templates and Python scripts such as "context" and "container" were not checked adequately, allowing a script to potentially access those objects without ensuring the necessary permissions on the part of the executing user. Who Is Affected? Sites that allow untrusted users to write Python Scripts, Page Templates, and DTML. Resolution This issue is resolved in Zope 2.6.3 and Zope 2.7.0 beta 4 and higher. Affected sites are strongly encouraged to update their Zope installations to prevent this issue. - Unpacking in untrusted code Issue Description Unpacking via function calls, variable assignment, exception variables and other contexts did not perform adequate security checks, potentially allowing access to objects that should have been protected. Who Is Affected? Sites that allow untrusted users to write Python Scripts, Page Templates, and DTML. Resolution This issue is resolved in Zope 2.6.3 and Zope 2.7.0 beta 4 and higher. Affected sites are strongly encouraged to update their Zope installations to prevent this issue. - Unicode passed to RESPONSE.write() could shutdown process Issue Description Inadequate type checking could allow unicode values passed to RESPONSE.write() to be passed into deeper layers of asyncore, where an exception would eventually be generated at a level that would cause the Zserver main loop to terminate. Who Is Affected? Sites that allow untrusted users to write Python Scripts, Page Templates, and DTML. Resolution This issue is resolved in Zope 2.6.3 and Zope 2.7.0 beta 4 and higher. Affected sites are strongly encouraged to update their Zope installations to prevent this issue. - PythonScript class security not initialized properly Issue Description Class security was not properly intialized for PythonScripts, potentially allowing access to variables that should be protected. It turned out that most of the security assertions were in fact activated as a side effect of other code, but this fix is still appropriate to ensure that all security declarations are properly applied. Who Is Affected? Sites that use Python Scripts. Resolution This issue is resolved in Zope 2.6.3 and Zope 2.7.0 beta 4 and higher. Affected sites are strongly encouraged to update their Zope installations to prevent this issue. - XML-RPC instance marshaling may disclose protected values Issue Description XML-RPC marshalling of class instances used the instance __dict__ to marshal the object, and could include attributes prefixed with an underscore name. These attributes are considered private in Zope and should generally not be disclosed. Who Is Affected? All Zope sites. Resolution This issue is resolved in Zope 2.6.3 and Zope 2.7.0 beta 4 and higher. Affected sites are strongly encouraged to update their Zope installations to prevent this issue. - DTML tag dtml-tree may allow DoS attack Issue Description The dtml-tree tag used an "eval" of user-supplied data; its efforts to prevent abuse were ineffective. Who Is Affected? All Zope sites. Resolution This issue is resolved in Zope 2.6.3 and Zope 2.7.0 beta 4 and higher. Affected sites are strongly encouraged to update their Zope installations to prevent this issue. - Potential cross-site scripting problem in default ZSearch interface Issue Description Browsers that do not escape html in query strings such as Internet Explorer 5.5 could potentially send a script tag in a query string to the ZSearch interface for cross-site scripting. Who Is Affected? Sites that use the default ZSearch interface. Resolution This issue is resolved in Zope 2.6.3 and Zope 2.7.0 beta 4 and higher. Affected sites are strongly encouraged to update their Zope installations to prevent this issue. - Proxy rights on DTMLMethods transferred via acquisition Issue Description DTMLMethods with proxy rights could incorrectly transfer those rights via acquisition when traversing to a parent object. Who Is Affected? Sites that allow users who have increased permissions in subfolders to write DTMLMethods. Resolution This issue is resolved in Zope 2.6.3 and Zope 2.7.0 beta 4 and higher. Affected sites are strongly encouraged to update their Zope installations to prevent this issue. - Improper security assertions on DTMLDocument objects Issue Description Some improper security assertions on DTMLDocument objects could potentially allow access to members that should be protected. Who Is Affected? Sites that use DTMLDocuments for secure content. Resolution This issue is resolved in Zope 2.6.3 and Zope 2.7.0 beta 4 and higher. Affected sites are strongly encouraged to update their Zope installations to prevent this issue. - PropertyManager 'lines' and 'tokens' properties stored as list Issue Description Some property types were stored in a mutable data type (list) which could potentially allow untrusted code to effect changes on those properties without going through appropriate security checks in particular scenarios. Who Is Affected? Sites that allow untrusted users to write Python Scripts, Page Templates, and DTML. Resolution This issue is resolved in Zope 2.6.3 and Zope 2.7.0 beta 4 and higher. Affected sites are strongly encouraged to update their Zope installations to prevent this issue. - Inadequate security assertions on admin "find" functions Issue Description Inadequate security assertions on administrative "find" methods could potentially be abused. Who Is Affected? All Zope sites. Resolution This issue is resolved in Zope 2.6.3 and Zope 2.7.0 beta 4 and higher. Affected sites are strongly encouraged to update their Zope installations to prevent this issue. - ZTUtils.SimpleTree state handling Issue Description The ZTUtils SimpleTree decompressed tree state data from the request without checking for final size, which could allow for certain types of DoS attacks. Who Is Affected? Sites that rely on the ZTUtils.SimpleTree. Resolution This issue is resolved in Zope 2.6.3 and Zope 2.7.0 beta 4 and higher. Affected sites are strongly encouraged to update their Zope installations to prevent this issue. - Configuration file did not override security policy selection Issue Description This is not really a security issue, just a usability issue. It has always been possible to alternate between C and Python implemenations of the Zope security policy using certain environment variables. As of Zope 2.7, use of environment variables is deprecated in favor of the new 2.7 configuration files. The new configuration machinery was not implementing the directive used to override the default security policy. Who Is Affected? Zope 2.7 beta users. Resolution This issue is resolved in Zope 2.6.3 and Zope 2.7.0 beta 4 and higher.

5 8

Re: [Zope3-dev] substransactions and beforeDelete
by Florent Guillaume 08 Jan '04

08 Jan '04

[Cc zope-dev and not zope3-dev anymore as my question is now zope 2 related...] Ok so Jim mentionned it was possible to do rollback of subtransactions in Zope 2. How can I do that ? What's the idiom that would be equivalent to: tid = startSubTransaction() ... if something: rollbackSubTransaction(tid) Thanks, Florent Steve Alexander wrote: > >>> Why are you catching the exception? >> >> >> Because I want to display a nice message to the user. If I don't catch >> the exception, it will go up to the Publisher that will display a >> not-nice error message. Hm are you suggesting I could provide a custom >> error message for that particular exception? That could work, but I >> would have like the flexibility of catching the exception from normal >> skin code and display my error message there. > > > Jim already mentioned a customised view on the exception. > > Another option that is not as architecturally clean, but might work > better for you, is to catch the exception, but doom the transaction. > > I wonder if it's a good idea to support having an application say "I > want to doom this transaction", and have the publication object just > abort that transaction without returning an error page. > > -- > Steve Alexander > > -- Florent Guillaume, Nuxeo (Paris, France) +33 1 40 33 79 87 http://nuxeo.com mailto:fg@nuxeo.com

2 1

Re: CVS: Zope/lib/python/Products/PluginIndexes/common - util.py:1.10.68.2
by Tres Seaver 07 Jan '04

07 Jan '04

Andreas Jung wrote: > Update of /cvs-repository/Zope/lib/python/Products/PluginIndexes/common > In directory cvs.zope.org:/tmp/cvs-serv8545/lib/python/Products/PluginIndexes/common > > Modified Files: > Tag: Zope-2_7-branch > util.py > Log Message: > - Using "_usage" parameters in a ZCatalog query is deprecated and > logged as DeprecationWarning. > > > === Zope/lib/python/Products/PluginIndexes/common/util.py 1.10.68.1 => 1.10.68.2 === > --- Zope/lib/python/Products/PluginIndexes/common/util.py:1.10.68.1 Mon Sep 29 08:02:02 2003 > +++ Zope/lib/python/Products/PluginIndexes/common/util.py Tue Jan 6 07:57:13 2004 > @@ -15,6 +15,7 @@ > > > import re > +from warnings import warn > from types import StringType,ListType,TupleType,DictType,InstanceType > from DateTime import DateTime > > @@ -65,7 +66,6 @@ > """ > > self.id = iid > - > if not request.has_key(iid): > self.keys = None > return > @@ -74,6 +74,7 @@ > usage_param = iid + '_usage' > if request.has_key(usage_param): > self.usage = request[usage_param] > + warn("\nZCatalog query using '%s' detected.\nUsing query parameters ending with '_usage' is deprecated.\nConsider using record-style parameters instead (see lib/python/Products/PluggableIndexes/README.txt for details)" % usage_param, DeprecationWarning) > > param = request[iid] > keys = None > Andreas, This checkin doesn't have accompanying changes to the tests (which now spew DeprecationWarnings on the 2.7 branch). It is also not propagated to the HEAD (only the doc/CHANGES.txt change made it there). Tres. -- =============================================================== Tres Seaver tseaver(a)zope.com Zope Corporation "Zope Dealers" http://www.zope.com

2 3

Zope 2.7 broken on Windows
by Andrew Veitch 06 Jan '04

06 Jan '04

http://collector.zope.org/Zope/1128 Not being able to use the calendar module on Zope 2.7 breaks our MailManager and more importantly the CMF! Has there been any progress on this? Or is there a sensible work-around I can give to our users - other than to switch to Linux! A

5 6

New-style classes and ClassSecurityInfo, fixed already?
by Mike C. Fletcher 06 Jan '04

06 Jan '04

http://zope.org/Collectors/Zope/1055 Is a bug report I filed a while ago for a fairly trivial breakage of the ClassSecurityInfo class due to the use of assignment to the class dictionary during the apply method. I'm wondering, is this fixed now on CVS head? I've been using a work-around module sub-class for Zope 2.7 work w/ new-style classes, but I can't imagine that's something that would be wanted as a solution. The ClassSecurityInfo.apply method is changed to use setattr instead of dict['x'] = y. The InitializeClass function also needs to have the same transformation applied to it. If desired I can pull the CVS tree and produce a diff if the problem isn't already solved. Have fun, Mike _______________________________________ Mike C. Fletcher Designer, VR Plumber, Coder http://members.rogers.com/mcfletch/

2 2

FileStorage instance has no attribute '_serial'
by Jeff Kowalczyk 06 Jan '04

06 Jan '04

I'm not sure whether the collector issue 1164 I posted is simply a missing configuration step on my part. At any rate, I'm still unable to start the current checkout of Zope HEAD. The only edit I make to /var/zope/etc/zope.conf is 'effective-user zuser', and the problem below also occurs if I then bin/runzope as root. Can anyone tell me if I'm missing something, or is this a bug? Thanks. [zuser@laptop Zope]$ ./configure [zuser@laptop Zope]$ make [root@laptop Zope]$ make install [root@laptop var]# /opt/Zope-2.8/bin/mkzopeinstance.py [root@laptop Zope]# chown -R zuser /var/zope/var [root@laptop Zope]# chgrp -R zuser /var/zope/var [zuser@laptop Zope]$ /var/zope/bin/runzope ------ 2004-01-04T23:06:08 INFO(0) ZServer HTTP server started at Sun Jan 4 23:06:08 2004 Hostname: localhost.localdomain Port: 8080 ------ 2004-01-04T23:06:08 INFO(0) ZServer FTP server started at Sun Jan 4 23:06:08 2004 Hostname: laptop Port: 8021 ------ 2004-01-04T23:06:10 DEBUG(-200) FileStorage create storage /var/zope/var/Data.fsTraceback (most recent call last): File "/opt/Zope-2.8/lib/python/Zope/Startup/run.py", line 49, in ? run() File "/opt/Zope-2.8/lib/python/Zope/Startup/run.py", line 19, in run start_zope(opts.configroot) File "/opt/Zope-2.8/lib/python/Zope/Startup/__init__.py", line 50, in start_zope starter.startZope() File "/opt/Zope-2.8/lib/python/Zope/Startup/__init__.py", line 218, in startZope Zope.startup() File "/opt/Zope-2.8/lib/python/Zope/__init__.py", line 46, in startup _startup() File "/opt/Zope-2.8/lib/python/Zope/App/startup.py", line 54, in startup DB = configuration.dbtab.getDatabase('/', is_root=1) File "/opt/Zope-2.8/lib/python/DBTab/DBTab.py", line 96, in getDatabase db = self._createDatabase(name, is_root) File "/opt/Zope-2.8/lib/python/DBTab/DBTab.py", line 113, in _createDatabase db = factory.open() File "/opt/Zope-2.8/lib/python/Zope/Startup/datatypes.py", line 172, in open DB = self.createDB() File "/opt/Zope-2.8/lib/python/Zope/Startup/datatypes.py", line 169, in createDB return ZODBDatabase.open(self) File "/opt/Zope-2.8/lib/python/ZODB/config.py", line 101, in open version_cache_size=section.version_cache_size) File "/opt/Zope-2.8/lib/python/ZODB/DB.py", line 98, in __init__ storage.store('\0\0\0\0\0\0\0\0', None, file.getvalue(), '', t) File "/opt/Zope-2.8/lib/python/ZODB/FileStorage.py", line 791, in store newserial=self._serial AttributeError: FileStorage instance has no attribute '_serial' [zuser@laptop var]$ ls -l /var/zope/var total 24 -rw-rw-r-- 1 zuser zuser 4 Jan 4 23:06 Data.fs -rw-rw-r-- 1 zuser zuser 103 Jan 4 23:06 Data.fs.index -rw-rw-r-- 1 zuser zuser 5 Jan 4 23:06 Data.fs.lock -rw-rw-r-- 1 zuser zuser 0 Jan 4 23:06 Data.fs.tmp -rw-r--r-- 1 zuser zuser 299 Jan 4 23:01 README.txt -rw-rw-r-- 1 zuser zuser 4 Jan 4 23:06 Z2.lock -rw-rw-r-- 1 zuser zuser 4 Jan 4 23:06 Z2.pid

2 2

Weird traceback on zopectl start (2.7b3, Python 2.3.2)
by sean.upton＠uniontrib.com 05 Jan '04

05 Jan '04

Got this traceback (below) on Zope 2.7b3 using Debian Python 2.3.2 running under Debian Sarge. Zope starts fine using bin/runzope, and even starts fine with zopectl - it just displays this traceback. Thoughts? intranet@lenny:~/z2/zope$ bin/zopectl start Traceback (most recent call last): File "/home/intranet/z2/Zope-2.7.0-b3/lib/python/Zope/Startup/zopectl.py", line 215, in ? main() File "/home/intranet/z2/Zope-2.7.0-b3/lib/python/Zope/Startup/zopectl.py", line 198, in main c.onecmd(" ".join(options.args)) File "/usr/lib/python2.3/cmd.py", line 210, in onecmd return func(arg) File "/home/intranet/z2/Zope-2.7.0-b3/lib/python/Zope/Startup/zopectl.py", line 134, in do_start ZDCmd.do_start(self, arg) File "/home/intranet/z2/zope/lib/python/zdaemon/zdctl.py", line 214, in do_start os.spawnvp(flag, args[0], args) File "/usr/lib/python2.3/os.py", line 543, in spawnvp return _spawnvef(mode, file, args, None, execvp) File "/usr/lib/python2.3/os.py", line 504, in _spawnvef wpid, sts = waitpid(pid, 0) OSError: [Errno 10] No child processes

1 0

Re: [Zope3-dev] template 'usage' (was Zope 3 Newsletter 11)
by Jim Fulton 05 Jan '04

05 Jan '04

Garrett Smith wrote: > I'm trying to get my head around the template 'usage' attribute -- I > know it should be simple, but the 'ah ha' hasn't hit me yet. > > It seems to me that 'usage' is just an abitrary way to configure a view > with a particular piece of information in ZCML. No. Usage has a for more specific purpose. Unfortunately, it's scope has expanded beyond it's fairly basic purpose. The usage variable was defined to solve a particular problem. We are used to thyinking about a standard look and feel for pages. The standard "page" macro is used to implement this standard look and feel. Unfortunately, there are a number of different kinds of pages. For example, some pages are like dialogs. For such pages, it doesn't make sense do display some page elements. We had created two page macros, "page" and "dialog". These macros were very similar and had overlapping contents. The folks working on these macros wanted to have a single macro and a variable to be used by the macro to disable some page elements depending on how the page was being used. So far so good. There is a notion that the page usage might be a configuration option. The thought is that the same template might be used for both "view" pages and "dialog" pages. I think that this is rather questionable. When someone designes a page, they probably know, or should know, how it is going to be used. To take things further, it was thought that all of the pages referenced by a manu should have the same usage and that the usage for a template should be *implied* by the menu that contains the menu item that references the page used by the template. I understand the motivation for this, but it is really problematic, for two reasons: 1. It is very implicit (automatic;) 2. The menu system just wasn't designed to support this sort of thing. The menu system is really only responsible for navigation. It is not responsible for implementation of referenced pages. Trying to do so adds lots of unwarrented complexity to the menu system. > This seems very useful, > but why limit it to a single value among a predefined set? Nah. > I can imagine a host a number of view-related (or whatever-related) > attributes being set via ZCML. E.g. > > - a view/form caption This already exists for forms. > - whether or not a page section is visible In general, YAGNI. For forms, you can control which fields are included. > - a URL to redirect to after an action has occurred I'd like to borrow some variation on this from the evolving form-navigation ideas developed for Plone. All of these parameter ideas are pretty specific. They are not well served by a general mechanism. > Short of requiring developers to create their own ZCML directives, could I'd rather have developers create their own ZCML directives. A generic mechanism will be too error prone or encourage folks to put too much ligic in their zpt. > we not handle these cases using an 'attributes' attribute, ala TALES? > E.g. in the case of usage now, an 'attributes' tag would look like this: > > <view name="foo" class="Foo" permission="zope.View" > attributes="usage objectview" /> > > I realize might be viewed as an erosion of well defined ZCML directives, > but it looks to me this is what 'usage' is doing anyway. I think an > 'attributes' attribute would be far more useful. I'm increasingly of the opinion that usage should be set in zpt, as it is, ultimately, an implementation decision. 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

2.7 dies when downloading file
by robert 05 Jan '04

05 Jan '04

Hi there, I would be gratefull if somebody could help with the following: calling the following piece of code lets Zope die. security.declareProtected(CMFCorePermissions.View, 'index_html') def index_html(self, RESPONSE): """ Produce a PDF for issue""" RESPONSE.setHeader('content-type', self.content_type()) RESPONSE.setHeader('content-length', str(self.get_size())) RESPONSE.setHeader('content-disposition', 'attachment;filename=i%s' % self.getFilename()) RESPONSE.write(self.getFile()) it produces the following traceback File "/home/zope/Zope-2.7-head/lib/python/Zope/Startup/run.py", line 49, in ? run() File "/home/zope/Zope-2.7-head/lib/python/Zope/Startup/run.py", line 19, in run start_zope(opts.configroot) File "/home/zope/Zope-2.7-head/lib/python/Zope/Startup/__init__.py", line 66, in start_zope Lifetime.loop() File "/home/zope/Zope-2.7-head/lib/python/Lifetime.py", line 43, in loop lifetime_loop() File "/home/zope/Zope-2.7-head/lib/python/Lifetime.py", line 53, in lifetime_loop asyncore.poll(timeout, map) File "/usr/lib/python2.3/asyncore.py", line 125, in poll write(obj) File "/usr/lib/python2.3/asyncore.py", line 81, in write obj.handle_error() File "/home/zope/Zope-2.7-head/lib/python/ZServer/medusa/http_server.py", line 440, in handle_error asynchat.async_chat.handle_error (self) File "/usr/lib/python2.3/asyncore.py", line 420, in handle_error self.close() File "/home/zope/Zope-2.7-head/lib/python/ZServer/HTTPServer.py", line 342, in close p.more() # free up resources held by producer AttributeError: more

1 0