[Zope-dev] Re: ZCatalog getObject broken

[Roché Compaan]

On Thu, 2005-03-10 at 12:13 -0500, Tres Seaver wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Chris McDonough wrote:
> | I implemented a "publisherTraverse" function like this FWIW:
> |
> | def publisherTraverse(context, path):
> |     # this is a hack to get around the fact that restrictedTraverse,
> |     # unlike publisher traversal, does checks at every step of the
> |     # path.  We don't want to limit access in this way (e.g. nested
> |     # shares are possible) so we reimplement restrictedTraverse in a
> |     # way that that emulates publisher traversal semantics
> |     ob = context.unrestrictedTraverse(path)
> |     user = getSecurityManager().getUser()
> |     if not user.has_permission('View', ob):
> |         raise zExceptions_Unauthorized, "cant traverse to %s" % path
> |     return ob
> 
> I don't think that the 'has_permission' check is quite right:  at least,
> that isn't what the publisher does.  'ZPublisher.BaseRequest.traverse'
> collects roles during the traversal, and then calls the user folder's
> 'validate', passing them at the end.  Note as well that 'View' may not
> be the permission which is protecting the traversed-to object).
> 
> The "correct" emulation would probably be to call the user object's
> 'authorize' method, passing the proper values for accessed, container,
> name, value, and roles.  Figuring out the proper values is left as an
> exercise for the reader ;).

Is it at all possible to figure out the proper values? Earlier in this
thread I asked if it is clear what value should be validated? It seems
to me that returning None when the user does not have access to the
object, imposes the same illogical constraint that the current
implementation does, in that it does not allow access to a method or
attribute of that object that is guarded less. One cannot predict when
calling getObject what method or attribute the user wants to access.

If it is possible to have access to a single method of the object but
nothing else of that object, then it doesn't make sense to do *any*
security checks in getObject. The object's own security assertions
should guard access to its attributes.


-- 
Roché Compaan
Upfront Systems                   http://www.upfrontsystems.co.za