Return-Path: 
 <users-return-18349-apmail-jackrabbit-users-archive=jackrabbit.apache.org@jackrabbit.apache.org>
X-Original-To: apmail-jackrabbit-users-archive@minotaur.apache.org
Delivered-To: apmail-jackrabbit-users-archive@minotaur.apache.org
Received: from mail.apache.org (hermes.apache.org [140.211.11.3])
	by minotaur.apache.org (Postfix) with SMTP id 6856299D4
	for <apmail-jackrabbit-users-archive@minotaur.apache.org>;
 Tue, 22 Nov 2011 19:00:32 +0000 (UTC)
Received: (qmail 43305 invoked by uid 500); 22 Nov 2011 19:00:31 -0000
Delivered-To: apmail-jackrabbit-users-archive@jackrabbit.apache.org
Received: (qmail 43269 invoked by uid 500); 22 Nov 2011 19:00:31 -0000
Mailing-List: contact users-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
List-Help: <mailto:users-help@jackrabbit.apache.org>
List-Unsubscribe: <mailto:users-unsubscribe@jackrabbit.apache.org>
List-Post: <mailto:users@jackrabbit.apache.org>
List-Id: <users.jackrabbit.apache.org>
Reply-To: users@jackrabbit.apache.org
Delivered-To: mailing list users@jackrabbit.apache.org
Received: (qmail 43261 invoked by uid 99); 22 Nov 2011 19:00:31 -0000
Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136)
    by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 22 Nov 2011 19:00:31 +0000
X-ASF-Spam-Status: No, hits=2.0 required=5.0
	tests=FREEMAIL_FROM,SPF_NEUTRAL,URI_HEX
X-Spam-Check-By: apache.org
Received-SPF: neutral (athena.apache.org: 216.139.236.26 is neither permitted
 nor denied by domain of amar.deka@gmail.com)
Received: from [216.139.236.26] (HELO sam.nabble.com) (216.139.236.26)
    by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 22 Nov 2011 19:00:27 +0000
Received: from joe.nabble.com ([192.168.236.139])
	by sam.nabble.com with esmtp (Exim 4.72)
	(envelope-from <amar.deka@gmail.com>)
	id 1RSvZe-0007iw-Kc
	for users@jackrabbit.apache.org; Tue, 22 Nov 2011 11:00:06 -0800
Date: Tue, 22 Nov 2011 11:00:06 -0800 (PST)
From: "amar.deka@gmail.com" <amar.deka@gmail.com>
To: users@jackrabbit.apache.org
Message-ID: <1321988406629-4096902.post@n4.nabble.com>
Subject: Trouble enforcing read-write ACL to Jackrabbit users on versionable
 nodes
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

(This question was cross-posted to 
http://stackoverflow.com/questions/8174226/trouble-enforcing-read-write-acl-to-jackrabbit-users-on-versionable-nodes
StatckOverflow.com  However I have not received any answer)
We are using Jackrabbit 2.2.7 to develop a repository for xml documents.

We want to create a bunch of users for the repository and enforce some sort
of read-only and read-write access privileges on them. We have used the
resource based ACL as described 
http://wiki.apache.org/jackrabbit/AccessControl#Resource-based_ACLs here .
Read-only permission works as charm. However, we are having hard time
getting read-write to work when a user attempts to create/delete a node that
is versionable (mix:versionable), even though we grant him the highest
possible privilege, Privilege.JCR_ALL. So far we have realized that the
modification to a versioned node actually is not simple. In Jackrabbit, it
span across multiple nodes - /jcr:system/jcr:versionStorage is one of them.
It seems that unless the user is the admin user himself, he cannot make
modification to /jcr:system/ and its child nodes.

So my questions are

a) is there a way I enable normal users to modify versionable nodes?
b) is there a way to create multiple admin users in jackrabbit (pointers,
wiki, code snippet)?
Here is the security section from the repository.xml:


<Security appName="Jackrabbit">
    <SecurityManager
class="org.apache.jackrabbit.core.DefaultSecurityManager" 
        workspaceName="security">
        
        
    </SecurityManager>

    <AccessManager 
        class="org.apache.jackrabbit.core.security.DefaultAccessManager">
        
    </AccessManager>

    <LoginModule 
       
class="org.apache.jackrabbit.core.security.authentication.DefaultLoginModule">
       
       
       
       
    </LoginModule>
</Security>

Here is how we are creating users and enabling access control:

{
        ...
        JackrabbitSession js = (JackrabbitSession) session;
        UserManager um = js.getUserManager();
        Authorizable grp = um.getAuthorizable("usergroup");
        Group userGroup = null;
        if(grp == null){
            userGroup = um.createGroup("usergroup");
        }else{
            userGroup = (Group) grp;
        }

        User user = um.createUser(newUserName, newUserPass);
        userGroup.addMember(user);

        Node node = session.getNode("/root");           

        AccessControlManager acm = session.getAccessControlManager();
        AccessControlList acl = getList(acm, node.getPath());

        Privilege[] privileges = null ;
        if(privilege.equals("r")){

            privileges = new Privilege[]
            {
                acm.privilegeFromName(Privilege.JCR_READ),
                acm.privilegeFromName(Privilege.JCR_LOCK_MANAGEMENT)
            };

        }else if(privilege.equals("rw")){
            privileges = new Privilege[]
            {

                acm.privilegeFromName(Privilege.JCR_ALL)
            };
        }else{

            return;
        }
        acl.addAccessControlEntry(new PrincipalImpl(user.getID()),
privileges);
        acm.setPolicy(node.getPath(), acl);

        session.save();
 }




--
View this message in context: http://jackrabbit.510166.n4.nabble.com/Trouble-enforcing-read-write-ACL-to-Jackrabbit-users-on-versionable-nodes-tp4096902p4096902.html
Sent from the Jackrabbit - Users mailing list archive at Nabble.com.