Hi,

One thing that causes a lot of confusion in the Plone world is that the 
<permission /> directive does not actually create permissions. Or 
rather, it does, in the Zope 3 sense, since it creates IPermission 
utilities, but in the Zope 2 sense, those are not permissions.

Five has a security policy that considers the 'title' attribute of an 
IPermission utility to contain a Zope 2 permission string, and calls 
getSecurityManager().checkPermission() with this as an argument.

The Zope 2 style permission has to come from somewhere else, though. It 
can come from an interaction with a ClassSecurityInfo, for example, or a 
view registration. At least, I think so, I can't really figure out how 
it works. :)

What I do know, is that a plain <permission /> is not enough, and that 
in some cases, nothing else will tickle the permission into existence. 
One example is if you created a permission only to use it in a CMF workflow.

The workaround is normally to call 
Products.CMFCore.permissions.setDefaultRoles. This has a comment that it 
ought to be in AccessControl, but basically it just modifies some 
AccessControl data structures to create a permission with a default set 
of roles.

I think the fact that this workaround is necessary is a bug. The 
<permission /> directive is supposed to be used to declare new 
permissions, but it does not do that fully in Zope 2. An easy bug fix 
would be to put something like this into Five:

     <subscriber
         for="zope.security.interfaces.IPermission
              zope.component.interfaces.IRegistered"
         handler=".permissions.create_permission"
         />


def create_permission(permission_utility, event):
     permission = permission_utilty.title
     roles = ()
     registered = _registeredPermissions
     if not registered.has_key(permission):
         registered[permission] = 1
         Products.__ac_permissions__=(
             Products.__ac_permissions__+((permission,(),roles),))
         mangled = pname(permission)
         setattr(ApplicationDefaultPermissions, mangled, roles)

The body of this function is copied from CMF's setSecurityInfo.

It'd also be nice if you could set up some app-root roles using the 
<grant /> directive from zope.securitypolicy, though I don't really know 
how that would work yet.

What do you think? Could we put this in as a bugfix?

Cheers,
Martin

-- 
Author of `Professional Plone Development`, a book for developers who
want to work with Plone. See http://martinaspeli.net/plone-book

_______________________________________________
Zope-Dev maillist  -  Zope-Dev@zope.org
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 )

Reply via email to