"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

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.

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  ?


Santi Camps

Zope-Dev maillist - [EMAIL PROTECTED]
** No cross posts or HTML encoding! **
(Related lists - http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )

Reply via email to