Products.Five: browser.view directive ignores access control directives.

Bug #578326 reported by Martijn Pieters on 2010-05-10
262
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Zope 2
Fix Released
High
Hanno Schlichting

Bug Description

The following zcml should protect the listed page with the zope2.Private permission (e.g. not viewable at all from the web):

  <configure
      xmlns="http://namespaces.zope.org/zope"
      xmlns:browser="http://namespaces.zope.org/browser">
  <browser:view
      name="foo"
      for="*"
      class=".foo.FooView
      permission="zope2.Private"
      >
    <browser:page name="bar attribute="bar" />
  </browser:view>
  </configure>

However, the @@foo/bar page is perfectly accessible, because the Products.Five.browser.metaconfigure.view configuration handler effectively ignores the permission.

There is in fact no way to protect a view (and the associated pages) from anonymous access with ZCML. The allowed_interface and allowed_attributes are similarly ignored.

Workaround: use old-style security=ClassSecurityInfo() markers on the view class itself. This only works with attribute-based pages.

visibility: private → public
Hanno Schlichting (hannosch) wrote :

Could you try to use a different permission, like "zope2.ViewManagementScreens" or "zope2.ManageUsers"?

I don't see any other mention of "zope2.Private" except in the permissions.zcml file in Five. It doesn't look like it's a valid permission in the AccessControl sense.

In site.zcml we have:

<meta:redefinePermission from="zope2.Public" to="zope.Public" />

which seems to take care of the public counterpart, but there's no such entry for the private one. It looks to me like the private permission is a decoy.

Martijn Pieters (mjpieters) wrote :

I used zope2.Private as an example. My real-world code used another permission altogether (custom in this case). But if you look at the code in question you can see that the permission is never used.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Martijn Pieters wrote:
> I used zope2.Private as an example. My real-world code used another
> permission altogether (custom in this case). But if you look at the code
> in question you can see that the permission is never used.

Can you please provide a functinoal test which demonstrates the failure
with a "stock" permission?

  status incomplete

Tres.
- --
===================================================================
Tres Seaver +1 540-429-0999 <email address hidden>
Palladion Software "Excellence by Design" http://palladion.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkvoSfcACgkQ+gerLs4ltQ7kewCg3Ki1JQ7qw/O6hqpccFlNdu7b
zU4AoNspGHpontePbrodFwETFSoSYY2i
=4NCN
-----END PGP SIGNATURE-----

Changed in zope2:
status: New → Incomplete
Hanno Schlichting (hannosch) wrote :

Triggered by a mailing list post on cmf-dev I looked over the code myself. The view directive indeed ignores the permission. The other directives use a "five:protectClass" directive to do something with it.

Changed in zope2:
importance: Undecided → High
status: Incomplete → Confirmed
Charlie_X (charlie) wrote :

I can confirm that this also applies to browser:page configuration.

Products.Five/browser/metaconfigure.py the culprit right? Views should behave like the Products.CMFDefault/formlib/form/ContentAddFormView which uses an explicit privacy declaration.

Charlie_X (charlie) wrote :

It looks like there is simply no test of a restricted view such as 'eagle.html' from a non-authenticated user.

Martijn Pieters (mjpieters) wrote :

Thanks for looking it over and confirming this Hanno, I kept forgetting to create a functional test for this.

Changed in zope2:
assignee: nobody → Hanno Schlichting (hannosch)
milestone: none → 2.12.9
Martin Aspeli (optilude) wrote :

Ok... I think this is fixed in 2.12 branch r114488 and merged to trunk in r114490.

Changed in zope2:
status: Confirmed → Fix Committed
Changed in zope2:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public Security information  Edit
Everyone can see this security related information.

Other bug subscribers