Upgrading to 2.2.0 (beta)

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.0b2 if you are using a source release.

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.