Upgrading to 2.2.0 (final release)

Binary changes

Zope 2.2 contains some changes to binaries since 2.1.x - you will need to re-run w_pcgi.py or wo_pcgi.py to rebuild your binaries after updating to 2.2.0b4 if you are using a source release.

Changes to the Zope security model

To address the server-side trojan issue, changes have been made to Zope security model for the 2.2 release. Certain aspects of the security model have been tightened which can in some cases affect third-party Zope products.

A How-to explaining the relevant changes to the security model has been made available to guide product authors who need to update their products to be compatible with 2.2. At the time of the 2.2 release, it is likely that some products will not yet be compatible. Zope users are encouraged to ensure that all of the products that they use are 2.2 compatible before attempting to upgrade important sites. Product authors are encouraged to update the supporting materials in their releases to note whether their products are 2.2 compatible. If you have problems with a Zope product after upgrading to Zope 2.2, please contact the product author and work with him to resolve the issue.

Zope site maintainers should note that the security model changes may affect the results returned by External Methods on their sites as well (especially if they return instances of custom Python classes). The material in the product author update guide is also relevant to these cases, so if you have authorization problems with your External Methods after upgrading be sure to read that document and make the recommended changes.

Setting ownership to prevent the server-side trojan issue

Managers of Zope sites that are vulnerable to the server-side trojan issue need to take steps to protect their sites beyond simply upgrading the underlying Zope software.

Zope 2.2 introduces the concept of "ownership" of objects - whenever an object is created, copied or imported the logged in user causing the operation becomes the owner of that object. Ownership now plays a role in the security model, as an owned "executable" (an object whose logic is supplied through the web) can perform operations only if its owner would be able to perform those operations. For details on the interaction between ownership and the security model, see the server-side trojan issue explanation.

Many users of Zope 2.2 will be upgrading an existing site, meaning an existing database with existing objects. Although Zope 2.2 adds software support for object ownership, the objects in your existing object database will initially be "unowned" after upgrading to 2.2. Unowned objects such as DTML method and DTML documents run with the same security rules as prior versions of Zope, meaning that they will run with the permissions of the user viewing/executing the object. This is, of course, the problem that ownership was introduced to avoid so if you have any untrusted users that provide their own content on your site you will need to set the ownership of objects on your site to the users responsible for those objects.

For existing sites, this may not be as easy as simply going to a web form, because under the new security model ownership may only be taken, not given away to an arbitrary user (for details on why, see the server-side trojan description). There is a facility for assigning ownership at the Python level, so most affected sites will want to create an external method to perform any needed ownership assignments. The following external method that will be used for Zope.org demonstrates how to set ownership from Python:

      import string

      def fixup_members(self):
          users=self.acl_users
          Members=self.Members
          r=[]
          for i in Members.objectIds():
              try:
                  u=users.getUserById(i)
                  m=getattr(Members, i)
              except: pass
              else:
                  if u is not None:
                    u=u.__of__(users)
                    m.changeOwnership(u)
                    r.append(i)
          return string.join(r,'\n')

This method demonstrates the general idea of what you want to do - grab an object that needs to become owned, then grab the user object which should be the owner (be sure the user is wrapped in the context of its user folder - that's what the __of__ call above does) and finally call the changeOwnership method of the object you want owned, passing the user object to be the owner.

Note that this is only necessary for sites that allow untrusted users to edit content - if your site does not do this, you may choose to do nothing about setting the ownership of existing objects. New objects that you create after upgrading to 2.2 will be owned, but the fact that your pre-existing objects are unowned should not cause any problems.

Changes to proxy roles

The updated security machinery in Zope 2.2 includes some changes to the way that proxy roles work. If you use proxy roles on your site, be sure to read the explanation of the server-side trojan issue, which describes the new behavior and the problem with the way that old-style proxy roles worked.