[Zope] RE: Zope Question entry: Security changes

[Brian Lloyd]

> Description:  (I posted this to zope-dev, but havent seen an 
> answer yet. Im adding it here so it doesnt get forgotten)
> 
> some questions raised by 
> http://www.zope.org/Documentation/How-To/ProductAuthorUpdateGuide
> 
> 
> Firstly, how does the presence of 
> __allow_access_to_unprotected_subobjects__=1 in a class 
> affect access to attributes in derived classes? Does it 
> affect the whole instance, or just attributes of the class 
> that includes it. In the following example I know subobject_2 
> is accessible, but what about the others?
> <example snipped>

Toby, 

(sorry not to get back to you earlier on this) 

The security assertion is generally tested on instances, so if 
an instance has the assertion in its class (or any of its base 
classes) then it is effective for all of the base classes of 
that object.


> Secondly, I am confused that there have not been any security 
> changes in ObjectManager.py and PropertyManager.py. As I 
> understand it, the subobjects that they manage (ie properties 
> and folder items) now fall into the inaccessible-by-default 
> category. What am I missing?

Actually there has been a change: the security assertion is in 
SimpleItem.Item (which acts as a base class for most, but not 
all, Zope objects). This is why "dynamic" attributes such as 
properties continue to work as before.

Your first reaction might be (as mine was) "well, doesn't that 
just put us right back where we were before?". Not quite. What 
has been done is a first step to changing the policy to deny-
by-default rather than allow-by-default. Having the assertion 
in the Item class has the effect of:

  o allowing access to properties and some other kinds of 
    attributes that are not currently explicitly protected, 
    needed for backward compatibility

  o DISallowing access to certain other things that the old 
    security rules would have allowed - for example under the 
    old rules alone it was possible to get to the func_globals and 
    other attributes of methods that you really shouldn't have 
    access to. We had to handle that with special cases, which 
    was painful and error prone (and only worked for problems that 
    you knew about). 

The new policy with the security assertion allows us to keep access 
to properties and things we _need_ access to for backward 
compatibility, but also has the effect of protecting things like 
method attributes and other (possibly unknown) bits that should be 
off limits (a method would need a security assertion of its own for
those things to be accessible). 

While this is not totally perfect and still requires you to be 
careful about protecting attributes of base classes, it is better 
than it was before and a first step on the road to where we want 
to be that shouldn't cause too much angst among users and product 
developers.

Hope this helps - I'm going to reformat this a little and add 
it to the Product author guide.


Brian Lloyd        brian@digicool.com
Software Engineer  540.371.6909              
Digital Creations  http://www.digicool.com