[Zope-dev] Re: CatalogBrains since Zope2.7.1b1

[Casey Duncan]

On Thu, 24 Jun 2004 09:59:30 +0000
Santi Camps <santi at zetadb.com> wrote:

>     "Security was tightened for getObject recently as part of a
>     general refactor of that code. I am happy to consider whether the
>     security is too tight, in which case it could be backed off a bit.
> 
>     Previously getObject performed no security checks and returned
>     objects for catalog results regardless of security permissions (it
>     used unrestrictedTraverse). I switched it to use
>     restrictedTraverse which checks security all the way down on all
>     of the containing folders and on the final object itself. This is
>     how path expressions work, for example."
> 
> I think this new security checks could be a problem in some cases. 
> They are Ok when using restricted code, but from trusted code I'm not
> sure that force to use restrictedTraverse could be considered a goal.

That is a good point, however since getObject is not itself a protected
method, and cannot tell whether it is being called by restricted code,
it must always do its own checking.

> For instance, imagin an application with employees of one department
> managing dossiers with economic data inside.  Employees of accounting
> department shouldn't have access to these dossiers objects, but they
> need to obtain some reports with a sum of all dossiers economic data. 
>  So, accounting department users shouldn't have access to dossiers
>  objects, but from reports trusted code these dossiers need to
>  accessed.
> 
> I think a possible solution could be an additional optional parameter
> of .getobject used from trusted code when unrestrictedTraverse want to
> be used.  What do you think  ?

Optional arguments will still allow untrusted code to bypass security
checks.

Here are three solutions to this, two of which do not involve catalog
changes:

- Use a proxy role on the script that invokes getObject which grants the
permissions needed.

- Use self.unrestrictedTraverse(brain.getPath()) from trusted code

- Add a private method: unrestrictedGetObject() to the catalog brain API
which does no security checking, but is inaccessible to untrusted code.

I think the last one is a good idea and I will implement it. The other
two are available options for now. 

The problem is that if the existing getObject offers a mode to do no
checking, it is conceivable for untrusted code to arrange for an object
to be cataloged whos path actually points to an otherwise inaccessible
object (granted a more likely senario is that the object is already
cataloged). It could then find that catalog result, call getObject() and
then pass it to the publisher to render it. This would allows a scripter
to publish any object in Zope, because it effectively gives them a way
to call unrestrictedTraverse.

-Casey