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