Re: [Zope-dev] Re: Bad interaction between Zope 2.7.3 and CMF 1.4
Note that I found it to be relevant which object I want to acquire (don't ask me why, though). E.g. going back to my CMFDefault examples, I *can* acquire portal_workflow and portal_url, but I can *not* acquire portal_membership and acl_users from a denied context. Go figure. If I change the test below to "app.wanted = PartlyProtectedSimpleItem3()" the test fails on current 2_7-branch ... Stefan On 12.10.2004, at 19:14, Tres Seaver wrote: +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') + -- The time has come to start talking about whether the emperor is as well dressed as we are supposed to think he is. /Pete McBreen/ ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: Bad interaction between Zope 2.7.3 and CMF 1.4
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.py27 Jan
2004 19:22:36 - 1.6.2.6
+++ lib/python/AccessControl/tests/testZopeSecurityPolicy.py12 Oct
2004 17:15:05 -
@@ -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.
--
===
Tres Seaver[EMAIL PROTECTED]
Zope Corporation "Zope Dealers" http://www.zope.com
___
Zope-Dev maillist - [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: Bad interaction between Zope 2.7.3 and CMF 1.4
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".
--
Dieter
___
Zope-Dev maillist - [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )
