Answering my own post ;-) Security does work, and was being applied, it's just still very much along 'allow by default'. Chris Withers wrote:
This class has no __roles__, no __ac_permissions__, no nothing... Instances of this class are stored within a special folderish class, Y.
Now the key here was the no __ac_permissions__ thing. Basically, this meant that default__class_init__ didn't add any roles as it usually does...
I thought Zope's security policy had changed to be disallow by default, but that really doesn't seem to be the case here :-S
It isn't, if you don't define __ac_permissions__ in any class, Acquiring or not, you're wide open :-( The patch is pretty simple: =================================================================== RCS file: /cvs-repository/Zope2/lib/python/App/class_init.py,v retrieving revision 1.5 diff -r1.5 class_init.py 125a126,131
for name, v in dict.items(): if not (hasattr(self,'__roles__') or have(name+'__roles__'): try: v.__roles__ = [] except dict[name+'__roles__'] = []
...which is quite harsh and simplistic. It's not tested and may have implications for things like self._properties and the like. But it's better to have access denied and fix that than not know what's hanging out, right? Also, having looked at class_init.py, it appears that if you leave methods out of __ac_permissions__, they're currently also completely open, which might be bad :-S (although I think the above patch takes care of that...) I guess the 'disallow by default' should really be implemented at the _checking_ stage, which currently says if you don't have a __roles__ attribute, anyone can do anything, but I understand there were other implications there. What were they? When will the move to disallow-by-default take place? cheers, Chris