Security Machinery doesn't work on some objects?
Hi there, I'm slightly confused by a class I have: class X(Persistent, Acquisition.Explicit): This class has no __roles__, no __ac_permissions__, no nothing... Instances of this class are stored within a special folderish class, Y. This folderish class has a __bobo_traverse__ which returns X objects, wrapped in context, from it's self._xs BTree using something along the lines of: def __bobo_traverse__(self, REQUEST, name): ob = getattr(self, name, _marker) if ob == _marker: ob = return self._xs[name].__of__(self) Now, it appears no methods or other attributes of this class are protected by the security machinery, even though the instances involved are wrapped. The DocString stuff still applies but, once a method has a docstring, any anonymous user who can traverse to one of these objects, can execute any method (attributes whinge about a missing docstring, how bizarre, attepting to traverse to __init__ complains the method starts with a _ ;-) of that instance which is more than a little disturbing ;-) 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 What am I missing out on? Is there some mixin class I need or something I need to acquire to make the security machinery check these objects? confusedly and worriedly, Chris
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
participants (1)
-
Chris Withers