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

> 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/,v
retrieving revision 1.5
diff -r1.5
>     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, 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?



Zope-Dev maillist  -  [EMAIL PROTECTED]
**  No cross posts or HTML encoding!  **
(Related lists - )

Reply via email to