If you add a user with the user manager, create a node, add an acl
that references the user, then remove the use from the user manager,
the following happens.
What is not entirely clear is the impact of this. Either the ACL fails
to get compiled and access to the node is denied, or, the exception is
caught somewhere and the statement gets ignored.
AFAICT, when this happens, loading the ACL template stops being
processed ignoring all later entries and access to the node is denied
altogether, meaning that if any principals are ever removed from a
JCR, any nodes where there are ACLs either granted or denied become
instantly inaccessible to all users.
Does that sound like a correct analysis ?
Whats the right course of action, never remove a user from the system ?
Patch the ACLTemplate to ignore NoSuchPrincipalExceptions ?
Find all ACLs that contain the principal and remove them ?
BTW, the last one may be imparctical where a PrincipalManager looks at
an external system. IMHO the best solution is going to be "Patch the
ACLTemplate to ignore NoSuchPrincipalExceptions " but thats Jackrabbit
code, not Sling ?
Ian
1.11.2009 16:11:29.951 *ERROR* [127.0.0.1 [1257091889782] GET /
_user.infinity.json HTTP/1.1]
org.apache.sling.jcr.resource.internal.helper.jcr.JcrNodeResource
listChildren: Cannot get children of JcrNodeResource,
type=sling:Folder, superType=null, path=/_user/private/01/32/cf/2d
org.apache.jackrabbit.api.security.principal.NoSuchPrincipalException:
Unknown principal user1-1257091867
at
org
.apache
.jackrabbit
.core
.security
.principal.PrincipalManagerImpl.getPrincipal(PrincipalManagerImpl.java:
75)
at
org
.apache
.sling
.jcr
.jackrabbit
.server.impl.security.standard.ACLTemplate.<init>(ACLTemplate.java:113)
at
org
.apache
.sling
.jcr
.jackrabbit
.server.impl.security.standard.ACLEditor.getACL(ACLEditor.java:92)
at
org
.apache.sling.jcr.jackrabbit.server.impl.security.standard.ACLProvider
$AclPermissions.buildResult(ACLProvider.java:586)
at
org
.apache
.jackrabbit
.core
.security
.authorization
.AbstractCompiledPermissions
.getResult(AbstractCompiledPermissions.java:46)
at
org
.apache
.jackrabbit
.core
.security
.authorization
.AbstractCompiledPermissions.grants(AbstractCompiledPermissions.java:82)
at
org
.apache.sling.jcr.jackrabbit.server.impl.security.standard.ACLProvider
$AclPermissions.grants(ACLProvider.java:673)
at
org
.apache
.jackrabbit
.core
.security.DefaultAccessManager.isGranted(DefaultAccessManager.java:232)
at
org
.apache
.jackrabbit
.core
.security.DefaultAccessManager.isGranted(DefaultAccessManager.java:220)
at org.apache.jackrabbit.core.ItemManager.canRead(ItemManager.java:339)
at
org.apache.jackrabbit.core.ItemManager.hasChildNodes(ItemManager.java:
567)
at org.apache.jackrabbit.core.NodeImpl.hasNodes(NodeImpl.java:2710)
at
org
.apache
.sling
.jcr
.resource
.internal.helper.jcr.JcrNodeResource.listChildren(JcrNodeResource.java:
237)
at
org
.apache
.sling
.jcr
.resource
.internal
.helper.jcr.JcrResourceProvider.listChildren(JcrResourceProvider.java:
107)
at org.apache.sling.jcr.resource.internal.helper.ResourceProviderEntry
$1.seek(ResourceProviderEntry.java:180)
at org.apache.sling.jcr.resource.internal.helper.ResourceProviderEntry
$1.<init>(ResourceProviderEntry.java:154)
at
org
.apache
.sling
.jcr
.resource
.internal
.helper.ResourceProviderEntry.listChildren(ResourceProviderEntry.java:
126)
