CMF security error in DCWorkflow that doesn't make sense
First of all, I'm not sure if this is the right mailing list but hopefully the DCWorkflow people read this list too. I've got a strange problem. On my laptop it works (zope 2.7.8) on the live server it works (zope 2.7.3) but on the test server (2.7.8) it doesn't!!! And it's the same Data.fs and Products as the live server. It throws an Unauthorized error upon executing a python script as part of a workflow transition. The Error: The owner of the executing script is defined outside the context of the object being accessed. The script has proxy roles, but they do not apply in this context.. Access to 'workflow' of (Products.DCWorkflow.Expression.StateChangeInfo instance at 0xddffb48) denied. Access requires Manage_portal_Permission, granted to the following roles: ['Manager']. The executing script is (PythonScript at /intranet/portal_workflow/intranet_workflow/scripts/wf_script_despatcher), owned by oliver. The Python script has Proxy role "Manager" so how can it be limited? I didn't write this CMF based application and I want to get on top of it so it doesn't happen again. Regards, Peter -- Peter Bengtsson, work www.fry-it.com home www.peterbe.com hobby www.issuetrackerproduct.com
Some progress. I managed to get it work by de-selecting the "Manager" role on the Proxy roles. Makes absolutely no sense. Later today I had another similar problem/error and nothing I changed on the Proxy roles mattered. I ended up replacing the Python Scipt with an External Method and that worked. This absolutely sucks. The DCWorkflow code is incredibly complicated and obscure and I hope it burns in hell. Having said that, I don't think I would do any better if I was to replicate what it can do :) 2008/7/1 Peter Bengtsson <peter@fry-it.com>:
First of all, I'm not sure if this is the right mailing list but hopefully the DCWorkflow people read this list too.
I've got a strange problem. On my laptop it works (zope 2.7.8) on the live server it works (zope 2.7.3) but on the test server (2.7.8) it doesn't!!! And it's the same Data.fs and Products as the live server. It throws an Unauthorized error upon executing a python script as part of a workflow transition. The Error:
The owner of the executing script is defined outside the context of the object being accessed. The script has proxy roles, but they do not apply in this context.. Access to 'workflow' of (Products.DCWorkflow.Expression.StateChangeInfo instance at 0xddffb48) denied. Access requires Manage_portal_Permission, granted to the following roles: ['Manager']. The executing script is (PythonScript at /intranet/portal_workflow/intranet_workflow/scripts/wf_script_despatcher), owned by oliver.
The Python script has Proxy role "Manager" so how can it be limited?
I didn't write this CMF based application and I want to get on top of it so it doesn't happen again.
Regards, Peter
-- Peter Bengtsson, work www.fry-it.com home www.peterbe.com hobby www.issuetrackerproduct.com
-- Peter Bengtsson, work www.fry-it.com home www.peterbe.com hobby www.issuetrackerproduct.com
Peter Bengtsson wrote at 2008-7-1 12:15 +0100:
... The owner of the executing script is defined outside the context of the object being accessed. The script has proxy roles, but they do not apply in this context.. Access to 'workflow' of (Products.DCWorkflow.Expression.StateChangeInfo instance at 0xddffb48) denied. Access requires Manage_portal_Permission, granted to the following roles: ['Manager']. The executing script is (PythonScript at /intranet/portal_workflow/intranet_workflow/scripts/wf_script_despatcher), owned by oliver.
The message tells you that the problem is the so called "executable owner" of the script. The "executable owner" is a mechanism to protect against Trojan horse attacks: a user with low priviledges creates an executable object that does bad things when executed by a user with high priviledges. The protection restricts the effective permissions to the intersection of the current user permissions and the executable owner permission. Probably, the executable owner of this script does not exist in your test instance (but it exists in the other instances). Use "take ownership" to change the executable owner (or create the executable owner). -- Dieter
participants (2)
-
Dieter Maurer -
Peter Bengtsson