#55 — Viewing history does not acquire permission settings

by Patrick Gerken — last modified Nov 26, 2009 12:11 AM
State Resolved
Version: 1.1.7
Area Functionality
Issue type Bug
Severity Low
Submitted by Patrick Gerken
Submitted on Nov 24, 2009
Responsible Alec Mitchell
Target release:
—
Return to tracker
In reality, I have this issue under 1.2.4.

If I set the "CMFEditions: Access previous versions"
Permission on a folder containing some versioned objects, these permissions are not taken into consideration when calling methods an the history metadata.
Apparently, the ZVCStorageTool returns a persistent history object that is in an acquisition wrapper.
If this is a feature, it is no where documented.
If this was not intended as a feature, I can write
a test case if requested.

Traceback:

Traceback (innermost last):
  Module ZPublisher.Publish, line 119, in publish
  Module ZPublisher.mapply, line 88, in mapply
  Module ZPublisher.Publish, line 42, in call_object
  Module Shared.DC.Scripts.Bindings, line 313, in __call__
  Module Shared.DC.Scripts.Bindings, line 350, in _bindAndExec
  Module Products.CMFCore.FSPageTemplate, line 216, in _exec
  Module Products.CMFCore.FSPageTemplate, line 155, in pt_render
  Module Products.Gloworm, line 28, in pt_render
  Module zope.pagetemplate.pagetemplate, line 117, in pt_render
   - Warning: Macro expansion failed
   - Warning: exceptions.KeyError: 'view_macro'
  Module zope.tal.talinterpreter, line 271, in __call__
  Module zope.tal.talinterpreter, line 346, in interpret
  Module zope.tal.talinterpreter, line 891, in do_useMacro
  Module zope.tal.talinterpreter, line 346, in interpret
  Module zope.tal.talinterpreter, line 536, in do_optTag_tal
  Module zope.tal.talinterpreter, line 521, in do_optTag
  Module zope.tal.talinterpreter, line 516, in no_tag
  Module zope.tal.talinterpreter, line 346, in interpret
  Module zope.tal.talinterpreter, line 957, in do_defineSlot
  Module zope.tal.talinterpreter, line 346, in interpret
  Module zope.tal.talinterpreter, line 536, in do_optTag_tal
  Module zope.tal.talinterpreter, line 521, in do_optTag
  Module zope.tal.talinterpreter, line 516, in no_tag
  Module zope.tal.talinterpreter, line 346, in interpret
  Module zope.tal.talinterpreter, line 861, in do_defineMacro
  Module zope.tal.talinterpreter, line 346, in interpret
  Module zope.tal.talinterpreter, line 957, in do_defineSlot
  Module zope.tal.talinterpreter, line 346, in interpret
  Module zope.tal.talinterpreter, line 536, in do_optTag_tal
  Module zope.tal.talinterpreter, line 521, in do_optTag
  Module zope.tal.talinterpreter, line 516, in no_tag
  Module zope.tal.talinterpreter, line 346, in interpret
  Module zope.tal.talinterpreter, line 949, in do_defineSlot
  Module zope.tal.talinterpreter, line 346, in interpret
  Module zope.tal.talinterpreter, line 586, in do_setLocal_tal
  Module zope.tales.tales, line 696, in evaluate
   - URL: file:/home/patrick/projects/syslabcom_git/denso.intranet/eggs/Products.CMFEditions-1.2.4-py2.4.egg/Products/CMFEditions/skins/CMFEditions/versions_history_form.pt
   - Line 7, Column 2
   - Expression: <PythonExpr history.getLength(countPurged=False)>
   - Names:
      {'container': <PloneSite at /denso-esc>,
       'context': <ATFile at /denso-esc/Projects/testprojekt/adsmsext.dll>,
       'default': <object object at 0x7f23e046b200>,
       'here': <ATFile at /denso-esc/Projects/testprojekt/adsmsext.dll>,
       'loop': {},
       'nothing': None,
       'options': {'args': ()},
       'repeat': <Products.PageTemplates.Expressions.SafeMapping object at 0xb02e320>,
       'request': <HTTPRequest, URL=http://127.0.0.1:8080/[…]/versions_history_form>,
       'root': <Application at >,
       'template': <FSPageTemplate at /denso-esc/versions_history_form used for /denso-esc/Projects/testprojekt/adsmsext.dll>,
       'traverse_subpath': [],
       'user': <MembraneUser 'projektleiter'>}
  Module Products.PageTemplates.ZRPythonExpr, line 49, in __call__
   - __traceback_info__: history.getLength(countPurged=False)
  Module PythonExpr, line 1, in <expression>
  Module AccessControl.ImplPython, line 727, in guarded_getattr
  Module AccessControl.ImplPython, line 669, in aq_validate
  Module AccessControl.ImplPython, line 563, in validate
  Module AccessControl.ImplPython, line 461, in validate
  Module AccessControl.ImplPython, line 808, in raiseVerbose
Unauthorized: Your user account does not have the required permission. Access to 'getLength' of (Products.CMFEditions.ZVCStorageTool.ShadowHistory object at 0xca66230) denied. Your user account, projektleiter, exists at /denso-esc/acl_users. Access requires one of the following roles: ['Contributor', 'Editor', 'Manager', 'Owner', 'Reviewer']. Your roles in this context are ['Authenticated'].
Steps to reproduce:
As a manager, create an folder
As a manager, set the "CMFEditions: Access previous versions" permission on the folder for authenticated users
As a manager, create a versionable object in the folder
As a manager, create a test user with no specific permissions
As the test user, try to access the previous versions of the object created in step 3
Added by Patrick Gerken on Nov 24, 2009 02:35 PM
After digging deeper because my local patch broke other things, I understand now that the ShadowHistory object is broken:
http://docs.zope.org/zope2/[…]cted-by-class-security-info

This clearly states that for security to work, objects must inherit from Acquisition.Implicit or Explicit. It doesn't do that. So either we should remove the security restrictions from the ShadowHistory itself, or add one of the two Acquisition base classes to the ShadowHistory bases.

Adding the base class and wrap the object will break other packages, like plone.app.layout...
Added by Alec Mitchell on Nov 24, 2009 05:49 PM
Issue state: Unconfirmed → Confirmed
Severity: Medium → Low
Responsible manager: (UNASSIGNED) → alecm
Looking at the source, it seems the permission context is the issue. The permission check is effectively being done on the repository tool, not the context. The history object in the template comes from `portal_repository.getHistoryMetadata`, which explicitly wraps the history object in the context of the tool in order to ensure that permissions are checked; it may be better and more consistent with the rest of the versioning code for the wrapping to be done in the object's context. The result is that the permissions on the object/folder are not currently relevant to whether the user can or cannot view the history, it is only the permissions on that tool that matter.

Should be easy to fix for 1.2.6
Added by Alec Mitchell on Nov 26, 2009 12:11 AM
Issue state: Confirmed → Resolved
This has been fixed in SVN

No responses can be added.