[Zope-dev] Request For Comments: SecurityJihad

Dieter Maurer dieter@handshake.de
Fri, 17 Aug 2001 19:34:24 +0200 (CEST)


Michael R. Bernstein writes:
 > > In fact, Python has only a weak policy towards privacy of objects
 > > starting with '_': they are not imported by "from xxx import *";
 > > nothing else is special about them.
 > > It is Zope that much more strictly enforces the privacy policy.
 > 
 > Ah, so this aspect of product development could be considered confusing
 > to experienced Python programmers who are new to Zope as well?
When I started Product development, I began with reading documentation.

What do you think did I learn quite early?

  *  docstring are essential for publishing

  *  attributes starting with '_' are private

 > ....
 > >   *  never saw any special handling for "manage_*" methods.
 > 
 > You mean that you've never seen it demonstrated? I think you said that
 > you always add explicit security directives anyway. The special handling
 > of 'manage_' methods only shows up if the method does not have an
 > explicit security statement.
No, I do not mean that.

   I looked intensively at ZPublishers code and there, I could not
   see any special handling of "manage_" methods.

 > ....
 > Ah. I see. Item and SimpleItem will not be changed acording to my
 > proposal. classes that derive from Item and Simpleitem (or other classes
 > derived from them) will continue to require either
 > '__allow_access_to_unprotected_subobjects__ = 0' or
 > 'security.setDefaultAccess("deny")'. This change was made for just the
 > backward compatibility reasons that you cite.Two new classes (SecureItem
 > and SimpleSecureItem, or something similar) will have a different
 > default policy for this purpose, and will not require derived classes to
 > re-override the policy.
Good!

 > ....
 > Only the docstring and 'manage_' behaviours are intended to be switched
 > off by default through the use of the new declarative security.
As I think, the "manage_" behaviour is not really there,
what remains is the docstring.

The docstring behaviour has two aspects:

  *  when an object did not have a docstring, ZPublisher
     would not publish it, independent of any other
     security assertion (that's the way, I always saw the rule).

     Thus, if someone wanted an object to be usable from
     DTML (or other TTW contexts), but did not want it
     to be published via the Web, he could do so by
     not providing a docstring.

     Your proposal may want to provide another,
     clearer and more explicite method for the
     (understandable) wish.

  *  when there have been not withstanding role assignments
     (the implementation of security declarations), then
     docstrings were sufficient for ZPublisher to publish
     the object.

     I agree with you, that this should take the global
     policy expressed by "__allow_access...." (or its lack)
     into account.

 > For those products that currently rely on the docstring and 'manage_'
 > behaviours *and* use declarative security, a way of turning those
 > behaviours back on will be provided, eg:
 > 
 > - security.docstringsMakePublishable("yes") 
 > 
 > - security.manageMethodNamesAreSpecial("yes")
I understood that and do not like it:

  When I say "__allow_access...=1" then the current
  docstring behaviour should remain.

  When I say "__allow_access...=0" or nothing at all,
  then it should go.


Dieter