Proposal: Align Zope 2 and Zope 3 permissions
Hi all, For a while now, people have had to contend with two ways of doing certain things, depending on whether the code they are working with is in "Zope 2 land" or "Zope 3 land". We're getting closer to a world where people don't need to be so intimately aware of the differences, especially since the __parent__ pointer work was merged, and some of the unification of page templates. However, we still have to do a lot of explaining in the realm of permissions. Five installs a Zope 3 security checker that checks against Zope 2 security. It does so by treating the title of a Zope 3 style IPermission utility as a Zope 2 permission string. This works well, and has allowed us to create valid Zope 3 permissions for the core Zope 2 and CMF permissions (e.g. zope2.View, cmf.ModifyPortalContent) for use in views and the like. However, it's not clear to new users where to use the Zope 3 style dotted name and where to use the Zope 2 permission string. As a rule of thumb, the rules are something like: - In ZCML (or a grok.require() directive) use the Zope 3 name - In code, e.g. when doing a checkPermission() call, use the Zope 2 name - With GenericSetup's rolemap.xml, use the Zope 2 name The waters are muddied further by components that require a permission to be listed or provided explicitly. Some use the Zope 2 name, some use the Zope 3 name. The other problem is that a <permission /> ZCML directive does not actually register a Zope 2 style permission, it merely maps an existing permission to a new name. Since Zope 2 permissions spring into existence in difficult-to-explain ways, that causes a lot of confusion. Finally, there is not total parity between Zope 2 security and Zope 3 security. Zope 2 cannot protect 'property set', for example. To this end, Five throws exceptions if you use a ZCML <class /> directive with set_attributes or or set_schema. Whilst this makes sense, it makes it harder to re-use existing packages that do have that kind of protection in place. Since the concept does not exist in Zope 2, I think it makes sense to ignore this with a warning, rather than error. So, here is what I'd like to propose, ideally for Zope 2.12: 1) Use an event handler to ensure that any <permission /> declared in ZCML actually creates a valid, Zope 2 permission. I have working code for this here which we could put in Products.Five with ease. http://dev.plone.org/collective/browser/collective.autopermission/trunk/coll... Benefits: Creating new permissions becomes more predictable. Risks: None obvious. The event handler will not override permissions that already exist. 2) Emit a warning instead of an error in Five's handler for the <class /> directive when set_attributes or set_schema are used. Benefits: Easier to re-use existing packages Risks: The attributes won't actually be protected. However, since Zope 2 doesn't have the concept of protecting 'set' (or security proxies) then I'm not sure there's a problem of expectation. 3) Change the Permission class in AccessControl so that it tries to look up an IPermission utility and use the title of that utility as the permission name, falling back on the current behaviour of using the passed permission name directly. Benefits: Should transparently allow any invocation of the Zope 2 API to use Zope 3 permission names, allowing us to document that the dotted permission name is the canonical name everywhere. Risks: Performance overhead of doing utility lookups. May result in name clashes, but since the permission name is a dotted name and the Zope 2 permission name isn't, I think it's extremely unlikely that this would actually happen in practice. Thoughts? Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book
On Sun, Apr 12, 2009 at 12:31, Martin Aspeli <optilude+lists@gmail.com> wrote:
Thoughts?
I haven't had my dead deeep down in the Zope 2 security for three years, so I'm a bit fuzzy on how it works, but all this sounds like a good step forward. +1 -- Lennart Regebro: Python, Zope, Plone, Grok http://regebro.wordpress.com/ +33 661 58 14 64
On Sun, Apr 12, 2009 at 12:31, Martin Aspeli <optilude+lists@gmail.com> wrote:
1) Use an event handler to ensure that any <permission /> declared in ZCML actually creates a valid, Zope 2 permission. I have working code for this here which we could put in Products.Five with ease.
http://dev.plone.org/collective/browser/collective.autopermission/trunk/coll...
Benefits: Creating new permissions becomes more predictable.
Risks: None obvious. The event handler will not override permissions that already exist.
2) Emit a warning instead of an error in Five's handler for the <class /> directive when set_attributes or set_schema are used.
Benefits: Easier to re-use existing packages
Risks: The attributes won't actually be protected. However, since Zope 2 doesn't have the concept of protecting 'set' (or security proxies) then I'm not sure there's a problem of expectation.
I like, +1.
3) Change the Permission class in AccessControl so that it tries to look up an IPermission utility and use the title of that utility as the permission name, falling back on the current behaviour of using the passed permission name directly.
Benefits: Should transparently allow any invocation of the Zope 2 API to use Zope 3 permission names, allowing us to document that the dotted permission name is the canonical name everywhere.
Risks: Performance overhead of doing utility lookups. May result in name clashes, but since the permission name is a dotted name and the Zope 2 permission name isn't, I think it's extremely unlikely that this would actually happen in practice.
I'm sure we can do some performance comparisons on this one. I'd say it's worth the cost, but hard numbers would help. -- Martijn Pieters
Martin Aspeli wrote:
So, here is what I'd like to propose, ideally for Zope 2.12:
1) Use an event handler to ensure that any <permission /> declared in ZCML actually creates a valid, Zope 2 permission. I have working code for this here which we could put in Products.Five with ease.
+1
2) Emit a warning instead of an error in Five's handler for the <class /> directive when set_attributes or set_schema are used.
+1
3) Change the Permission class in AccessControl so that it tries to look up an IPermission utility and use the title of that utility as the permission name, falling back on the current behaviour of using the passed permission name directly.
-1 I think we should start advertising the zope.security API for this instead. For example: from zope.security import checkPermission checkPermission('zope2.Private', context) This works by looking up the current security interaction from a thread local, which in Five's case is a FiveSecurityPolicy. This policy delegates to the checkPermission function found in Products.Five.security which does exactly what you want: if (permission in ('zope.Public', 'zope2.Public') or permission is None or permission is CheckerPublic): return True if isinstance(permission, basestring): permission = queryUtility(IPermission, unicode(permission)) if permission is None: return False if getSecurityManager().checkPermission(permission.title, object): return True return False
Hanno Schlichting wrote:
Martin Aspeli wrote:
So, here is what I'd like to propose, ideally for Zope 2.12:
1) Use an event handler to ensure that any <permission /> declared in ZCML actually creates a valid, Zope 2 permission. I have working code for this here which we could put in Products.Five with ease.
+1
2) Emit a warning instead of an error in Five's handler for the <class /> directive when set_attributes or set_schema are used.
+1
3) Change the Permission class in AccessControl so that it tries to look up an IPermission utility and use the title of that utility as the permission name, falling back on the current behaviour of using the passed permission name directly.
-1
I think we should start advertising the zope.security API for this instead. For example:
from zope.security import checkPermission checkPermission('zope2.Private', context)
This works by looking up the current security interaction from a thread local, which in Five's case is a FiveSecurityPolicy. This policy delegates to the checkPermission function found in Products.Five.security which does exactly what you want:
Oh, that's interesting. I had no idea that'd work. That would indeed solve the inconsteincy for manual permission checks. It would not help with any of the RoleManager APIs, though, e.g. how to change permissions on an object. It also wouldn't fix rolemap.xml in GS, MembershipTool.checkPermission and similar, but we could fix those independently. Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book
Martin Aspeli wrote at 2009-4-12 18:31 +0800:
.... Finally, there is not total parity between Zope 2 security and Zope 3 security. Zope 2 cannot protect 'property set', for example.
Since Zope 2.8, Zope 2 could in principle -- and until quite recently I thought, it really can: it only fails with the "context" check (is the accessed object in the context of the UserFolder authenticating the current user). Of course, such checks fail for objects not acquisition wrapped. If we let pass this check in such cases, Zope 2 can protect property sets. -- Dieter
Dieter Maurer wrote:
Martin Aspeli wrote at 2009-4-12 18:31 +0800:
.... Finally, there is not total parity between Zope 2 security and Zope 3 security. Zope 2 cannot protect 'property set', for example.
Since Zope 2.8, Zope 2 could in principle -- and until quite recently I thought, it really can: it only fails with the "context" check (is the accessed object in the context of the UserFolder authenticating the current user). Of course, such checks fail for objects not acquisition wrapped. If we let pass this check in such cases, Zope 2 can protect property sets.
Not sure I understand you here. How would I declare that 'set' of an attribute (property) is protected by one permission and 'get' is protected by another? Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book
Martin Aspeli wrote at 2009-4-12 18:31 +0800:
... 3) Change the Permission class in AccessControl so that it tries to look up an IPermission utility and use the title of that utility as the permission name, falling back on the current behaviour of using the passed permission name directly.
Benefits: Should transparently allow any invocation of the Zope 2 API to use Zope 3 permission names, allowing us to document that the dotted permission name is the canonical name everywhere.
Risks: Performance overhead of doing utility lookups. May result in name clashes, but since the permission name is a dotted name and the Zope 2 permission name isn't, I think it's extremely unlikely that this would actually happen in practice.
You probably should be careful with this: if not done carefully, you may end up doing the utility lookup not once but once at each object on the path from the accessed object to the root. -- Dieter
Martin Aspeli wrote: I've now implemented 1 and 2 on trunk, since they seem pretty non-controversial.
1) Use an event handler to ensure that any <permission /> declared in ZCML actually creates a valid, Zope 2 permission. I have working code for this here which we could put in Products.Five with ease.
and
2) Emit a warning instead of an error in Five's handler for the <class /> directive when set_attributes or set_schema are used.
I've not done this yet:
3) Change the Permission class in AccessControl so that it tries to look up an IPermission utility and use the title of that utility as the permission name, falling back on the current behaviour of using the passed permission name directly.
I'd like to solicit a bit more input before attempting this, as I got at least one -1. I think this is the bigger win, though, and I'd still like to do it unless performance becomes prohibitive or it turns out to be too invasive a change. Cheers, Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Martin Aspeli wrote:
I've not done this yet:
3) Change the Permission class in AccessControl so that it tries to look up an IPermission utility and use the title of that utility as the permission name, falling back on the current behaviour of using the passed permission name directly.
I'd like to solicit a bit more input before attempting this, as I got at least one -1.
I think this is the bigger win, though, and I'd still like to do it unless performance becomes prohibitive or it turns out to be too invasive a change.
- -1: I think both of those will be true. I also don't see much win. The major goal should be to unify the API for add-ons, rather than the implementation: your #1 and #2 alaready did that, I think. Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJ44jx+gerLs4ltQ4RAjvwAKCN7uLoypk4eFBDqD6/mC8yW0Sc4ACfTktE YYCdpj8NREIpSXT1Tt7Wsms= =IdzH -----END PGP SIGNATURE-----
Tres Seaver wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Martin Aspeli wrote:
I've not done this yet:
3) Change the Permission class in AccessControl so that it tries to look up an IPermission utility and use the title of that utility as the permission name, falling back on the current behaviour of using the passed permission name directly. I'd like to solicit a bit more input before attempting this, as I got at least one -1.
I think this is the bigger win, though, and I'd still like to do it unless performance becomes prohibitive or it turns out to be too invasive a change.
- -1: I think both of those will be true. I also don't see much win.
The major goal should be to unify the API for add-ons, rather than the implementation: your #1 and #2 alaready did that, I think.
I had a deeper look last night, and I think this would be more invasive than I'd feared. I thought originally the Permission class was used everywhere, but on further inspection, I see that manually constructed '_Permission' strings are used in a lot of places, including C code. It frightens me slightly that, having pdb'd my way through AccessControl a number of times, I still have only a fuzzy idea about how the permissions system works, and I haven't found any solid documentation with the code. I think to unify the API, we'd need to: - Promote the zope.security checkPermission method like Hanno suggested - Change rolemap.xml in GenericSetup to accept Zope 2 names - Look at other places where permission names are passed around in code (there are a few places in Plone, for instance) and make sure we always prefer the Zope 3 dotted name. Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book
Hey, Martin Aspeli wrote: [snip]
- In ZCML (or a grok.require() directive) use the Zope 3 name
Grok also has a grok.Permission you can subclass, and those subclasses can also be passed to grok.require().
- In code, e.g. when doing a checkPermission() call, use the Zope 2 name - With GenericSetup's rolemap.xml, use the Zope 2 name
We haven't gotten around to making grok.Permission subclasses useful here yet in Grok, but we should. [various proposal]
Thoughts?
I'm +1 on this, though with the caveat that I'm quite far from Zope 2 right now so I don't have a full picture of the impact. But it looks like a good way to move Zope 2 closer to the Zope Toolkit approach. Regards, Martijn
Martijn Faassen wrote:
Hey,
Martin Aspeli wrote: [snip]
- In ZCML (or a grok.require() directive) use the Zope 3 name
Grok also has a grok.Permission you can subclass, and those subclasses can also be passed to grok.require().
I know, but I kind of consider creating permissions by subclassing grok.Permission an anti-pattern. That is, I don't like the idea of using Python classes purely for declarative configuration. That's the kind of thing that ought to sit in a configuration file, IMHO, and ZCML works fine for that kind of thing. But I digress. ;)
- In code, e.g. when doing a checkPermission() call, use the Zope 2 name - With GenericSetup's rolemap.xml, use the Zope 2 name
We haven't gotten around to making grok.Permission subclasses useful here yet in Grok, but we should.
[various proposal]
Thoughts?
I'm +1 on this, though with the caveat that I'm quite far from Zope 2 right now so I don't have a full picture of the impact. But it looks like a good way to move Zope 2 closer to the Zope Toolkit approach.
Like I said, I think fixing it at the low level AccessControl API would be more invasive than I'd first thought. I'm not sure it's a safe thing to attempt right now... Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book
participants (7)
-
Dieter Maurer -
Hanno Schlichting -
Lennart Regebro -
Martijn Faassen -
Martijn Pieters -
Martin Aspeli -
Tres Seaver