[Zope-dev] restrictedTraverse

Stuart Bishop zen@shangri-la.dropbear.id.au
Thu, 16 May 2002 16:57:57 +1000


On Sunday, May 12, 2002, at 01:27  AM, Florent Guillaume wrote:

> With an object path /A/B/C where C has a local role allowing a user to
> view C but where B disallows acquisition of the View permission, the
> publisher correctly allows the user to see C.
>
> However restrictedTraverse('/A/B/C') fails ("You are not allowed to
> access B in this context"). This is because restrictedTraverse checks
> the security (using "validate") at *every* step, and obviously the
> user is not allowed to see B.  Is there a reason for this ? Why not
> simply validate only at the last step ?

Note that it doesn't check for the View permission though - it
checks for the 'Access contents information' permission. If this
fails, it fails because the site manager has explicitly said
that a group of users is not allowed to access any objects below
this point.

If restrictedTraverse did not behave live this, a site manager would
need to check the permissions on every single object in a subtree if
they needed to restrict access to it, as well as every single object
created in that subtree in the future. The current behaviour means
that someone with 'Manage permissions' cannot make an object world
viewable if it is in an area that the site manager has designated
as restricted. It means that an object can be created in a
restricted area and it stays restricted, even if it defaults to
world viewable (such as an object that defines
__allow_access_to_unprotected_subobjects__=1, or objects dynamically
created from external sources like the file system or an RDBMS).

> I have the need to programatically access object protected in such a
> way. The workaround I'm going to use in my code for now is to call
> unrestrictedTraverse and validate() by hand the resulting object.  But
> I'm concerned that there may be a more profound security reason I'm
> missing.

You may end up exposing an object that was never meant to be
exposed to the user, as previously it was relying on permissions
set in a parent container?

You may be better off by granting the 'Access contents information'
on B or allowing it to be aquired.

--
Stuart Bishop <zen@shangri-la.dropbear.id.au>
http://shangri-la.dropbear.id.au/