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/