You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@jackrabbit.apache.org by ABAM <in...@hotmail.com> on 2012/05/03 00:18:47 UTC
AccessControll
Hello
I have a issue that I can not find answer for here or in Jackrabbit
documentation, hope that any of you can help with it.
I am doing the following:
- admin create "someuser"
- admin create the above node:
/templates/templateall[
jcr:uuid: a9b629a4-d1dd-4ba3-a602-629e4ca1a7fd
jcr:mixinTypes: mix:referenceable, rep:AccessControllable,
label: templateall
jcr:primaryType: nt:unstructured
/templates/templateall/rep:policy[
jcr:primaryType: rep:ACL
/templates/templateall/rep:policy/allow[
rep:privileges: jcr:all,
rep:principalName: someuser
jcr:primaryType: rep:GrantACE
- someuser try to delete /templates/templateall node with the following
exception on save()
javax.jcr.AccessDeniedException: /templates/templateall: not allowed to
remove item
at
org.apache.jackrabbit.core.ItemSaveOperation.validateTransientItems(ItemSaveOperation.java:704)
at
org.apache.jackrabbit.core.ItemSaveOperation.perform(ItemSaveOperation.java:216)
at
org.apache.jackrabbit.core.session.SessionState.perform(SessionState.java:216)
at org.apache.jackrabbit.core.ItemImpl.perform(ItemImpl.java:91)
at org.apache.jackrabbit.core.ItemImpl.save(ItemImpl.java:329)
at
org.apache.jackrabbit.core.session.SessionSaveOperation.perform(SessionSaveOperation.java:64)
at
org.apache.jackrabbit.core.session.SessionState.perform(SessionState.java:216)
at org.apache.jackrabbit.core.SessionImpl.perform(SessionImpl.java:361)
at org.apache.jackrabbit.core.SessionImpl.save(SessionImpl.java:812)
- After, I try to delete /templates/templateall with admin user and the
delete is completed successfully.
- Then I try to do the same but I give user "someuser" jcr:all access to
node /templates instead of /templates/templateall, then "someuser" is able
to delete the /templates/templateall successfully
So my conclusion with the first structure example is: "someuser" can remove
any child of node /templates/templateall but not the node itself, is
necesary to provide jcr:removeChildNodes acess no /templates to be able to
do that.
Is my conclusion correct?
Thanks!!
--
View this message in context: http://jackrabbit.510166.n4.nabble.com/AccessControll-tp4604580.html
Sent from the Jackrabbit - Users mailing list archive at Nabble.com.
Re: AccessControll
Posted by Angela Schreiber <an...@adobe.com>.
hi
> - Create user "someuser"
> - Create /agb:Templates/agb:TemplateRead and /agb:Templates/agb:TemplateAll
> nodes.
> - User "someuser" be able to delete& modify agb:TemplateAll node.
> - User "someuser" be able to just read (not delete, not update)
> agb:TemplateRead node.
>
> I order to do that I create the bellow structure but with the bellow
> structure "someuser" is able to delete
> /agb:Templates/agb:TemplateRead/agb:DatatypeProperties,
really? if you only granted jcr:removeChildNodes on (any) parent node
and the effective permissions on
/agb:Templates/agb:TemplateRead/agb:DatatypeProperties just was 'read'
and 'removeChildNode',
the removal should fail upon save... if it doesn't this was a bug
that should be reported into jira including a regular test case
that illustrates the issue. can you test, what was the result of
JackrabbitAccessControlManager#getPrivilege(String, Set<Principal>)
using the admin session and Session#hasPermission(String, String[])
with your someone session for the given target path?
> this is a expected
> behavior due to the jcr:removeChildNodes added on /agb:Templates but is not
actually this isn't expected. see above.
kind regards
angela
Re: AccessControll
Posted by ABAM <in...@hotmail.com>.
Hello Angela, thank you very much for your response.
I try to follow your recommendation but I still have issues.
What I am trying to do is (behavior that I am trying to achieve):
- Create user "someuser"
- Create /agb:Templates/agb:TemplateRead and /agb:Templates/agb:TemplateAll
nodes.
- User "someuser" be able to delete & modify agb:TemplateAll node.
- User "someuser" be able to just read (not delete, not update)
agb:TemplateRead node.
I order to do that I create the bellow structure but with the bellow
structure "someuser" is able to delete
/agb:Templates/agb:TemplateRead/agb:DatatypeProperties, this is a expected
behavior due to the jcr:removeChildNodes added on /agb:Templates but is not
desire according to my goal, I can not remove jcr:removeChildNodes from
/agb:Templates becuase I need it in order to be able to delete
/agb:Templates/agb:TemplateAll and the nodes bellow.
What I think I can do to get my goal is add a "deny jcr:removeChildNodes"
Jackrabbit access on /agb:Templates/agb:TemplateRead. Thinking in more users
and nodes I think is not the best think to do. Do you think of any other
approach that I can try to achieve the behavior that I want?
Hope you can help me and again thank you very much.
/agb:Templates[
jcr:mixinTypes: rep:AccessControllable,
agb:label: Templates
jcr:primaryType: nt:unstructured
/agb:Templates/rep:policy[
jcr:primaryType: rep:ACL
/agb:Templates/rep:policy/allow[
rep:privileges: jcr:removeChildNodes, jcr:readAccessControl,
rep:principalName: someuser
jcr:primaryType: rep:GrantACE
/agb:Templates/agb:TemplateRead[
jcr:uuid: 8cf35f57-c8fa-4efd-ab4f-26b8eb5baf51
jcr:mixinTypes: mix:referenceable, rep:AccessControllable,
agb:label: template read
jcr:primaryType: nt:unstructured
/agb:Templates/agb:TemplateRead/rep:policy[
jcr:primaryType: rep:ACL
/agb:Templates/agb:TemplateRead/rep:policy/allow[
rep:privileges: jcr:read, jcr:readAccessControl,
rep:principalName: someuser
jcr:primaryType: rep:GrantACE
/agb:Templates/agb:TemplateRead/agb:DatatypeProperties [
agb:label: DatatypeProperties
jcr:primaryType: nt:unstructured
/agb:Templates/agb:TemplateRead/agb:ObjectProperties[
agb:label: ObjectProperties
jcr:primaryType: nt:unstructured
/agb:Templates/agb:TemplateAll[
jcr:uuid: f3d65b65-110e-4e45-98f1-97fe727113f9
jcr:mixinTypes: mix:referenceable, rep:AccessControllable,
agb:label: template all
jcr:primaryType: nt:unstructured
/agb:Templates/agb:TemplateAll/rep:policy[
jcr:primaryType: rep:ACL
/agb:Templates/agb:TemplateAll/rep:policy/allow[
rep:privileges: jcr:all,
rep:principalName: someuser
jcr:primaryType: rep:GrantACE
/agb:Templates/agb:TemplateAll/agb:DatatypeProperties[
agb:label: DatatypeProperties
jcr:primaryType: nt:unstructured
/agb:Templates/agb:TemplateAll/agb:ObjectProperties[
agb:label: ObjectProperties
jcr:primaryType: nt:unstructured
--
View this message in context: http://jackrabbit.510166.n4.nabble.com/AccessControll-tp4604580p4606411.html
Sent from the Jackrabbit - Users mailing list archive at Nabble.com.
Re: AccessControll
Posted by Angela Schreiber <an...@adobe.com>.
hi
> What I am trying to do is the following:
>
> Create users "user1", "user2"
>
> Create structure:
> /templatesNode/template1Node/.../
> /template2Node/.../
> /template3Node/.../
> /template4Node/.../
>
> "user1" be able to delete and write on template1Node and template2Node
> "user2" be able to delete and write on template3Node and template4Node
>
> So in order to do that I need to:
> - Provide on /templatesNode jcr:removeChildNodes access to user1 and user2
> - Provide /template1Node and /template2Node all access to user1
well... not all... i would just grant jcr:read, jcr:write and
jcr:nodeTypeManagement.
> - Provide /template3Node and /template4Node all access to user2
same here.
> But like that user1 can remove template3Node and template4Node and user2 can
> remove template1Node and template2Node.
why that? in order to be able to remove a node you must have both
privileges. jcr:removeChildNodes on the parent AND jcr:removeNode
on the target node itself. so, user1 will not be able to remove
template3Node if he/she is only granted jcr:removeChildNode on
the parent...
> With the little knowledge of Jackrabbit a solution can be deny removeNode o
> template3Node and template4Node to user1 and do the same for user2 on
> template1Node and template2Node, but I am planing to have many users and
> many nodes under templatesNode so I think is not a solution.
you don't have to remove jcr:removeNode privilege if it hasn't
been granted before. and as far as i understood your user1
would not have any kind of write permission on the template3Node.
so, i think it does what you expected.
> Do you a better approach to what I am trying to do?
from time to time its possible to simplify things using
an additional pattern-matching restriction with the access
control entries. but that requires a naming pattern that is
suitable for this.
kind regards
angela
> Thank you!
>
> --
> View this message in context: http://jackrabbit.510166.n4.nabble.com/AccessControll-tp4604580p4605812.html
> Sent from the Jackrabbit - Users mailing list archive at Nabble.com.
Re: AccessControll
Posted by ABAM <in...@hotmail.com>.
Hi Angela, thanks for the soon response.
I am really new using Jackrabbit so I do no understand the "unlink" part in
the documentation, but I will read and make some examples to get it.
What I am trying to do is the following:
Create users "user1", "user2"
Create structure:
/templatesNode/template1Node/.../
/template2Node/.../
/template3Node/.../
/template4Node/.../
"user1" be able to delete and write on template1Node and template2Node
"user2" be able to delete and write on template3Node and template4Node
So in order to do that I need to:
- Provide on /templatesNode jcr:removeChildNodes access to user1 and user2
- Provide /template1Node and /template2Node all access to user1
- Provide /template3Node and /template4Node all access to user2
But like that user1 can remove template3Node and template4Node and user2 can
remove template1Node and template2Node. This is something that my
requirement is trying to avoid.
With the little knowledge of Jackrabbit a solution can be deny removeNode o
template3Node and template4Node to user1 and do the same for user2 on
template1Node and template2Node, but I am planing to have many users and
many nodes under templatesNode so I think is not a solution.
Do you a better approach to what I am trying to do?
Thank you!
--
View this message in context: http://jackrabbit.510166.n4.nabble.com/AccessControll-tp4604580p4605812.html
Sent from the Jackrabbit - Users mailing list archive at Nabble.com.
Re: AccessControll
Posted by Angela Schreiber <an...@adobe.com>.
hi
> So my conclusion with the first structure example is: "someuser" can remove
> any child of node /templates/templateall but not the node itself, is
> necesary to provide jcr:removeChildNodes acess no /templates to be able to
> do that.
> Is my conclusion correct?
yes that's correct. see JSR 283 section 16.2.3 Standard Privileges:
"• jcr:removeChildNodes: The privilege to remove child nodes of
a node.
In order to actually remove a node requires jcr:removeNode on that
node and jcr:removeChildNodes on the parent node. The distinction is
provided in order to distinguish implementations that internally
model a “remove” as a “delete” from those that model it as an
“unlink”. A repository that uses the “delete” model can have
jcr:removeChildNodes in every access control policy, so that removal
is effectively controlled by jcr:removeNode. Conversely, a repository
that uses the “unlink” model can have jcr:removeNode in every access
control policy."
hope that helps
angela
> Thanks!!
>
> --
> View this message in context: http://jackrabbit.510166.n4.nabble.com/AccessControll-tp4604580.html
> Sent from the Jackrabbit - Users mailing list archive at Nabble.com.