[Zope] External Methods, Proxy Roles, and Executable Security

[George Lee]

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 at 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 at 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
> >
>