Tres Seaver wrote:
Dieter Maurer wrote:
Tres Seaver wrote at 2004-10-9 12:04 -0400:
Stefan H. Holek wrote:
While testing a large-ish customer project under Zope 2.7.3 we found that when an object with setDefaultAccess('deny') is used as the context for a PythonScript, the script can no longer aquire tools from the portal root.
*By definition*, anybody who has declared 'setDefaultAccess('deny') *wants* the behavior you describe: that declaration says, "unless I give you explicit permission for using a name, refuse."
I do *NOT* think that this is the intended semantics of "setDefaultAccess('deny')".
In my view, "setDefaultAccess(XXX)" should only affect objects that do not have security declarations themselves. Acquired tools have security declarations -- they should not be affected by "setDefaultAccess".
If Plone has classes which make such assertions, then either the authors *meant* them, or they need to be removed. This is (literally) the same thing as declaring '__allow_access_to_unprotected_subobjects__ = 0' in your class.
With this name, it becomes even clearer:
Acquires tools are neither "unprotected" nor "subobjects".
Hmm, I tried writing a test te verify that my change (after 2.7.2) had modified the security policy's behavior. Here is the test, which I expected to pass on the head of the 2.7 branch, but fail on 2.7.2:
--- lib/python/AccessControl/tests/testZopeSecurityPolicy.py 27 Jan 2004 19:22:36 -0000 1.6.2.6 +++ lib/python/AccessControl/tests/testZopeSecurityPolicy.py 12 Oct 2004 17:15:05 -0000 @@ -336,6 +336,16 @@ else: self.fail('Policy accepted bad __roles__')
+ def test_no_acquisition_through_paranoid(self): + + # Check that acquisition through a paranoid object is not allowed. + app = App() + app.wanted = UnprotectedSimpleItem() + app.enabling = UnprotectedSimpleItem() + app.blocking = RestrictedSimpleItem() + self.assertPolicyAllows(app.enabling, 'wanted') + self.assertPolicyDenies(app.blocking, 'wanted') +
def test_suite(): return unittest.makeSuite(ZopeSecurityPolicyTests)
However, it passes for both. Anyone care to speculate why?
Tres.
OK, so my change was specifically to 'guarded_getattr', so the test was exercising the wrong thing. Note that this means that the old behaviour of guarded_getattr was allowing objects to be returned which wouldn't be validated (I think). Here is a test for 'guarded_getattr', which *fails* both before and after my change: --- lib/python/AccessControl/tests/testZopeGuards.py 16 Jan 2004 21:04:54 -0000 1.1.4.3 +++ lib/python/AccessControl/tests/testZopeGuards.py 12 Oct 2004 17:51:13 -0000 @@ -24,11 +24,14 @@ import AccessControl.SecurityManagement from AccessControl.SimpleObjectPolicies import ContainerAssertions from zExceptions import Unauthorized +from Acquisition import Explicit from AccessControl.ZopeGuards \ import guarded_getattr, get_dict_get, get_dict_pop, get_list_pop, \ get_iter, guarded_min, guarded_max, safe_builtins, guarded_enumerate, \ guarded_sum, guarded_apply +from testZopeSecurityPolicy \ + import App, UnprotectedSimpleItem, RestrictedSimpleItem try: __file__ except NameError: @@ -112,6 +115,17 @@ self.assertEqual(values.args, (d, 'values')) finally: ContainerAssertions[_dict] = old + + def test_no_acquisition_through_paranoid(self): + + # Check that acquisition through a paranoid object is not allowed. + app = App() + app.wanted = UnprotectedSimpleItem() + app.enabling = UnprotectedSimpleItem() + app.blocking = RestrictedSimpleItem() + ok = self.guarded_getattr(app.enabling, 'wanted') + self.assertRaises(Unauthorized, + self.guarded_getattr, app.blocking, 'wanted') class TestGuardedGetattrC(TestGuardedGetattrPy): Aargh! Tres. -- =============================================================== Tres Seaver tseaver@zope.com Zope Corporation "Zope Dealers" http://www.zope.com