You are viewing a plain text version of this content. The canonical link for it is here.

Posted to users@jackrabbit.apache.org by ChadDavis <ch...@gmail.com> on 2011/07/25 22:12:14 UTC

ACL and Version Control

I'm using ACL's to control access to subtrees.  This works great, but
I noticed that now my version control stuff fails because it doesn't
have the proper access.  I can get this to work, but I can't really
decide what the best way of addressing this is.

1) when I create my Jackrabbit users ( I'm using the jackrabbit user
management extensions ), their content subtrees and the associated
ACL's, I could attempt to also attach an ACL for that user to the
version control tree.  This, however, strikes me as a bit odd, and
perhaps unwieldy.

OR

2) I can simply user a repo-wide admin user, who has access to
everything, do these actions.

How do other folks handle this?  Thoughts?

Re: ACL and Version Control

Posted by ChadDavis <ch...@gmail.com>.

On Wed, Jul 27, 2011 at 2:13 AM, Angela Schreiber <an...@adobe.com> wrote:
> hi chad
>
>> I suppose this could be a bug in the davex remoting stack, on the
>> service side of the equation.
>
> could be. can you provide a test case that allows me to reproduce the
> problem? that would be helpful.

I've created a test case.  However, it's not such a simple thing.  My
unit test has to fire up the a remote server, running the
jackrabbit-webapp WAR, then set up the repo with the ACL for the user.
 It's far too much to paste on the list here.  I can send you my JUnit
test class if you like.  But here's the main snippet, slightly
pseudo-ized.

Assume:

1) user has jcr:all on node a
2) user has read only on jcr:system tree

Test Code:

		Node a = clientSession.getRootNode().getNode("a");
		Node b = myNode.addNode("b");
		b.addMixin("mix:versionable");
		clientSession.save();
		VersionManager versionManager =
clientSession.getWorkspace().getVersionManager();
		Version version = versionManager.checkin(b.getPath());

		//add a version label
		VersionHistory versionHistory = versionManager.getVersionHistory(b.getPath());
		String versionLabel = "Version One";
		boolean replaceLabelWithSameName = false;
		versionHistory.addVersionLabel(version.getName(), versionLabel,
replaceLabelWithSameName);
		clientSession.save();

RESULTS:

1) checkin succeeds
2)  addVersionLabel fails with AccessDeniedException

Re: ACL and Version Control

Posted by Angela Schreiber <an...@adobe.com>.

hi chad

> I suppose this could be a bug in the davex remoting stack, on the
> service side of the equation.

could be. can you provide a test case that allows me to reproduce the
problem? that would be helpful.

> Or is this expected by your understanding?

not really.

>> note however, that this only covers the execution. reading
>> version related content is controlled by regular read permissions.
>> one more thing to be aware of: version operations such as checkin
>> also require read-access to the corresponding part of the version
>> storage. this is rather cumbersome and covered by an jira issue [2]
>
> I'm not entirely sure that I understand this, and the referenced
> ticket.  Are you saying that successful version control operations,
> such as checkin, depend upon BOTH:
>
> 1) jcr:versionManagement on the node which will be versioned
> 2) read access to the entire version tree, i.e. /jcr:system/jcr:versionStorage

yes as a matter of fact since there is not reasonable way to restrict
the access on the versionstorage.

> I understand requirement one easily enough.  And I think I understand
> number two -- I'm using the Default . . . AccessManager,
> SecurityManager and LoginModule, and I'm using admin/admin.  I have
> attached no ACL's to anything in the system tree, so I would expect
> that my admin user has read permissions on the entire version tree.

yes. admin has all permissions everywhere.

> Actually, I would expect that my other users also have read access on
> that tree; perhaps I'm wrong here?

that obviously depends on the permission you set up.

regards
angela

Re: ACL and Version Control

Posted by ChadDavis <ch...@gmail.com>.

> I'm using an admin user, who has this privilege.  And, indeed, the
> checkin() works, and a new version is created.  However, when I try to
> add a label, I get a RepositoryException.  If I remove the label call,
> the checkin operation works just fine.
>
> javax.jcr.RepositoryException: Forbidden
>        at org.apache.jackrabbit.spi2dav.ExceptionConverter.generate(ExceptionConverter.java:120)
>        at org.apache.jackrabbit.spi2dav.ExceptionConverter.generate(ExceptionConverter.java:51)
>        at org.apache.jackrabbit.spi2dav.RepositoryServiceImpl.execute(RepositoryServiceImpl.java:552)
>        at org.apache.jackrabbit.spi2dav.RepositoryServiceImpl.addVersionLabel(RepositoryServiceImpl.java:1766)
>        at org.apache.jackrabbit.jcr2spi.WorkspaceManager$OperationVisitorImpl.visit(WorkspaceManager.java:1061)
>        at org.apache.jackrabbit.jcr2spi.operation.AddLabel.accept(AddLabel.java:70)
>        at org.apache.jackrabbit.jcr2spi.WorkspaceManager$OperationVisitorImpl.execute(WorkspaceManager.java:848)
>        at org.apache.jackrabbit.jcr2spi.WorkspaceManager$OperationVisitorImpl.access$400(WorkspaceManager.java:793)
>        at org.apache.jackrabbit.jcr2spi.WorkspaceManager.execute(WorkspaceManager.java:581)
>        at org.apache.jackrabbit.jcr2spi.version.VersionManagerImpl.addVersionLabel(VersionManagerImpl.java:146)
>        at org.apache.jackrabbit.jcr2spi.version.VersionHistoryImpl.addVersionLabel(VersionHistoryImpl.java:179)
>        at wego.ecms.WGECMSDocumentManager.commitVersion(WGECMSDocumentManager.java:487)
>

Actually, I usually see the following exception.


javax.jcr.AccessDeniedException: Access denied.
	at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
	at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
	at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
	at java.lang.reflect.Constructor.newInstance(Constructor.java:501)
	at org.apache.jackrabbit.spi2dav.ExceptionConverter.generate(ExceptionConverter.java:69)
	at org.apache.jackrabbit.spi2dav.ExceptionConverter.generate(ExceptionConverter.java:51)
	at org.apache.jackrabbit.spi2dav.RepositoryServiceImpl.execute(RepositoryServiceImpl.java:552)
	at org.apache.jackrabbit.spi2dav.RepositoryServiceImpl.addVersionLabel(RepositoryServiceImpl.java:1766)
	at org.apache.jackrabbit.jcr2spi.WorkspaceManager$OperationVisitorImpl.visit(WorkspaceManager.java:1061)
	at org.apache.jackrabbit.jcr2spi.operation.AddLabel.accept(AddLabel.java:70)
	at org.apache.jackrabbit.jcr2spi.WorkspaceManager$OperationVisitorImpl.execute(WorkspaceManager.java:848)
	at org.apache.jackrabbit.jcr2spi.WorkspaceManager$OperationVisitorImpl.access$400(WorkspaceManager.java:793)
	at org.apache.jackrabbit.jcr2spi.WorkspaceManager.execute(WorkspaceManager.java:581)
	at org.apache.jackrabbit.jcr2spi.version.VersionManagerImpl.addVersionLabel(VersionManagerImpl.java:146)
	at org.apache.jackrabbit.jcr2spi.version.VersionHistoryImpl.addVersionLabel(VersionHistoryImpl.java:179)
	at wego.ecms.WGECMSDocumentManager.commitVersion(WGECMSDocumentManager.java:487)

Re: ACL and Version Control

Posted by ChadDavis <ch...@gmail.com>.

Thanks Angela.

> in order to execute version operations a principal must
> have jcr:versionManagement privilege [1] on the corresponding
> versionable node.

I'm using an admin user, who has this privilege.  And, indeed, the
checkin() works, and a new version is created.  However, when I try to
add a label, I get a RepositoryException.  If I remove the label call,
the checkin operation works just fine.

javax.jcr.RepositoryException: Forbidden
	at org.apache.jackrabbit.spi2dav.ExceptionConverter.generate(ExceptionConverter.java:120)
	at org.apache.jackrabbit.spi2dav.ExceptionConverter.generate(ExceptionConverter.java:51)
	at org.apache.jackrabbit.spi2dav.RepositoryServiceImpl.execute(RepositoryServiceImpl.java:552)
	at org.apache.jackrabbit.spi2dav.RepositoryServiceImpl.addVersionLabel(RepositoryServiceImpl.java:1766)
	at org.apache.jackrabbit.jcr2spi.WorkspaceManager$OperationVisitorImpl.visit(WorkspaceManager.java:1061)
	at org.apache.jackrabbit.jcr2spi.operation.AddLabel.accept(AddLabel.java:70)
	at org.apache.jackrabbit.jcr2spi.WorkspaceManager$OperationVisitorImpl.execute(WorkspaceManager.java:848)
	at org.apache.jackrabbit.jcr2spi.WorkspaceManager$OperationVisitorImpl.access$400(WorkspaceManager.java:793)
	at org.apache.jackrabbit.jcr2spi.WorkspaceManager.execute(WorkspaceManager.java:581)
	at org.apache.jackrabbit.jcr2spi.version.VersionManagerImpl.addVersionLabel(VersionManagerImpl.java:146)
	at org.apache.jackrabbit.jcr2spi.version.VersionHistoryImpl.addVersionLabel(VersionHistoryImpl.java:179)
	at wego.ecms.WGECMSDocumentManager.commitVersion(WGECMSDocumentManager.java:487)


I suppose this could be a bug in the davex remoting stack, on the
service side of the equation.  Or is this expected by your
understanding?


>
> note however, that this only covers the execution. reading
> version related content is controlled by regular read permissions.
> one more thing to be aware of: version operations such as checkin
> also require read-access to the corresponding part of the version
> storage. this is rather cumbersome and covered by an jira issue [2]

I'm not entirely sure that I understand this, and the referenced
ticket.  Are you saying that successful version control operations,
such as checkin, depend upon BOTH:

1) jcr:versionManagement on the node which will be versioned

AND

2) read access to the entire version tree, i.e. /jcr:system/jcr:versionStorage

I understand requirement one easily enough.  And I think I understand
number two -- I'm using the Default . . . AccessManager,
SecurityManager and LoginModule, and I'm using admin/admin.  I have
attached no ACL's to anything in the system tree, so I would expect
that my admin user has read permissions on the entire version tree.
Actually, I would expect that my other users also have read access on
that tree; perhaps I'm wrong here?

Re: ACL and Version Control

Posted by Angela Schreiber <an...@adobe.com>.

hi chad

in order to execute version operations a principal must
have jcr:versionManagement privilege [1] on the corresponding
versionable node.

note however, that this only covers the execution. reading
version related content is controlled by regular read permissions.
one more thing to be aware of: version operations such as checkin
also require read-access to the corresponding part of the version
storage. this is rather cumbersome and covered by an jira issue [2]

hope that helps
angela

[1] 
http://www.day.com/maven/jsr170/javadocs/jcr-2.0/javax/jcr/security/Privilege.html#JCR_VERSION_MANAGEMENT
[2] https://issues.apache.org/jira/browse/JCR-2963

On 7/25/11 10:12 PM, ChadDavis wrote:
> I'm using ACL's to control access to subtrees.  This works great, but
> I noticed that now my version control stuff fails because it doesn't
> have the proper access.  I can get this to work, but I can't really
> decide what the best way of addressing this is.
>
> 1) when I create my Jackrabbit users ( I'm using the jackrabbit user
> management extensions ), their content subtrees and the associated
> ACL's, I could attempt to also attach an ACL for that user to the
> version control tree.  This, however, strikes me as a bit odd, and
> perhaps unwieldy.
>
> OR
>
> 2) I can simply user a repo-wide admin user, who has access to
> everything, do these actions.
>
> How do other folks handle this?  Thoughts?