You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by Ian Boston <ia...@caret.cam.ac.uk> on 2009/11/01 17:26:01 UTC
ACL's and users who have been removed.
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)
Re: ACL's and users who have been removed.
Posted by Ian Boston <ie...@tfd.co.uk>.
This has been fixed in the Jackrabbit 1.6.0 onwards.
Do we want to upgrade, I cant remember the back compatibility issues
with 1.6 ?
(I have a modified ACLTemplate so I don't need to, but if this hits
others, then it might make sense)
Ian
On 1 Nov 2009, at 16:26, Ian Boston wrote:
> 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)
>