p.s. This is in the context of a external method in a workflow scripts folder, if that helps. Peace, George On 11/19/05, George Lee <georgeleejr@gmail.com> wrote:
In CMFCore 1.5.4:
If a low-security-clearance user calls an external method that pastes an object from a PortalFolder, he gets an error because the following line in CMFCore.PortalFolder fails:
if not sm.checkPermission(DeleteObjects, parent): raise AccessControl_Unauthorized
This is even the case if "sm.checkPermission" is changed to "_checkPermission", which takes into account proxy roles. The external method does not allow proxy roles attached, so I can't just add a "Manager" proxy role.
Because I called the pasting in an external method, I expected it to go through without security problems! Is this a right expectation / and a bug, or a wrong expectation?
Peace, George
On 11/18/05, George Lee <georgeleejr@gmail.com> wrote:
I forget if I submitted a collector issue about this before, but I didn't see it. I just posted one at <http://www.zope.org/Collectors/CMF/396>:
Title: PortalFolder.py _verifyObjectPaste ignores executable security
Version info: CMF 1.5.4 but also in trunk
_verifyObjectPaste calls "sm.checkPermission(permission_name,self)" rather than "_checkPermission(permission_name,self)"
This makes it ignore executable security. So, if _verifyObjectPaste is in an external method or in a script with sufficient proxy roles, it raises an Unauthorized error for users when the external method / proxy role security should suffice.
On 9/9/05, Dieter Maurer <dieter@handshake.de> wrote:
George Lee wrote at 2005-9-8 23:57 -0400:
... Is it okay to just replace sm.checkPermission with _checkPermission from CMFCore.utils or is that not okay?
Yes. But, please file a bug report as well.
Also Dieter I noticed that Alan Runyan and you briefly discussed this issue back in 2002: http://mail.zope.org/pipermail/zope-cmf/2002-September/015350.html
Any internal use should always take executable security (i.e. executable ownership and proxy roles) into account. Not doing so is a but, as things expected to be possible are not and (maybe even worse) things expected to be impossible may be possible.
There may be a need for application code to check the permissions of the user with proxy roles not taken into account.
E.g. a script that must use a "Manager" roles to do one thing but does not want to do another unless the current user has specific permissions.
For this case, there also should be a method checking permissions with proxy roles not taken into account.
-- Dieter