manifoldcf-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Karl Wright <daddy...@gmail.com>
Subject Re: ManifoldCf Documentum Negative ACL
Date Thu, 06 Apr 2017 21:52:56 GMT
Hi Sharnel,

I've created CONNECTORS-1401 to track this issue; I will try to get to it
tonight or tomorrow.  As you probably know, we are planning to release MCF
2.7 by the end of the month, so once I have a patch ready, I'd greatly
appreciate you trying it out to be sure it functions as designed.

Thanks,
Karl


On Thu, Apr 6, 2017 at 5:34 PM, Sharnel Merdeck Pereira <
spereire@worldbankgroup.org> wrote:

> Hi Karl.
>
>
>
> Thanks for taking the time to check.
>
>
>
> Below is the implementation in documentum.
>
>
>
> -          Document
>
> o   Each Document has an ACL
>
> §  ACL can have Groups and Users
>
> §  Groups can further have subgroups and Users
>
> §  Access level is given to Group or User *only at ACL level.*
>
>
>
> o   When a user belongs to a group with r_accessor_permit=1 or
> r_accessor_permit=2, the user should not have READ access to the acl.
>
>
>
> Considering above, answers to questions in below mail :
>
>
>
> 1.      implies that the way 'negative groups' have been added to
> Documentum is by somehow designating groups as 'negative'. Is this
> correct?  Or are groups designated negative only within the context of
> individual ACLs?
>
>
>
> Answer: Groups or Users are given permission only at ACL level. Yes,
> groups /user designated negative only within the context of individual ACLs
>
>
>
> As in the below example . Permission is given only at ACL level.
>
>
>
>
>
> *object_name*
>
> *  r_accessor_name*
>
> *r_accessor_permit  *
>
> *r_is_group*
>
> Document 1
>
>
>
>
>
>
>
>
>
>
>
> ACL_1
>
>
>
>
>
>
>
>
>
>
>
> GroupA
>
> 3
>
> T
>
>
>
>
>
> GroupB
>
> 1
>
> T
>
>
>
>
>
> GroupC
>
> 6
>
> T
>
>
>
>
>
> User1
>
> 3
>
> F
>
>
>
>
>
> User2
>
> 1
>
> F
>
> GroupA
>
> GroupD
>
> GroupE
>
> User2
>
> User4
>
> GroupD
>
> User4
>
> User5
>
> GroupB
>
> User6
>
> User7
>
> GroupF
>
>
>
>
>
> -          User2 is part of Group A, ACL_1 has READ(3) access for GroupA
> but NONE(1) access for User2. Hence lowest access takes precedence, User2
> won’t have access to ACL_1.
>
>
>
> -          User4 is part of Group A and has READ(3) access to ACL_1
>
>
>
> -          User 5 is part of GroupD, GroupD belongs to GroupA which has
> READ(3) access to Document, hence User5 has access to ACL_1
>
>
>
> -          User6 belongs to GroupB, Group B has NONE(1) access to
> Document and hence User6 has NONE access to ACL_1
>
>
>
> -          if User/Group/ParentGroup has *r_accessor_name* in ACL, the
> lowest *r_accessor_permit  *takes precedence.
>
>
>
> The query
>
> *select r_accessor_name, r_accessor_permit, r_is_group from dm_acl where
> object_name =’<aclName>’ *
>
> will retrieve accessor_name and permission for acl.
>
>
>
> The query
>
> *            select distinct i_supergroups_names from dm_group where
> group_name in (select group_name from dm_group where any users_names
> =’<userName>’)*
>
>                         will retrieve user groups. As from above example
> for User5, query will return both GroupD and GroupA
>
>
>
> Thanks
>
> Sharnel
>
>
>
>
>
> *From:* Karl Wright [mailto:daddywri@gmail.com]
> *Sent:* Thursday, April 06, 2017 2:49 AM
> *To:* user@manifoldcf.apache.org
> *Subject:* Re: ManifoldCf Documentum Negative ACL
>
>
>
> Hi Shamel, I've done some further research.
>
>
>
> (1) There is currently only one access token ever stored with a Documentum
> document -- it's the name of the ACL associated with that document.
>
> (2) The Documentum connector does not fire off any of its own DQL at this
> time for finding the document's ACL.  This is how it currently does it,
> using DFC methods all the way:
>
>
>
> >>>>>>
>
> strarrACL[0] = docbaseName + ":" + object.getACLDomain() + "." +
> object.getACLName();
>
> <<<<<<
>
>
>
> ... where:
>
>
>
> >>>>>>
>
>   /** Get the ACL domain */
>
>   public String getACLDomain()
>
>     throws DocumentumException, RemoteException
>
>   {
>
>     try
>
>     {
>
>       return ((IDfSysObject)object).getACLDomain();
>
>     }
>
>     catch (DfException e)
>
>     {
>
>       throw new DocumentumException("Documentum exception:
> "+e.getMessage());
>
>     }
>
>   }
>
>
>
>   /** Get the ACL name */
>
>   public String getACLName()
>
>     throws DocumentumException, RemoteException
>
>   {
>
>     try
>
>     {
>
>       return ((IDfSysObject)object).getACLName();
>
>     }
>
>     catch (DfException e)
>
>     {
>
>       throw new DocumentumException("Documentum exception:
> "+e.getMessage());
>
>     }
>
>   }
>
> <<<<<<
>
>
>
> (3) Your statement:
>
>
>
> 'acl idocs_inst_540278_O_acl has negative group added to it
> (r_accessor_name: emucw ; r_accessor_permit :1)'
>
>
>
> ...implies that the way 'negative groups' have been added to Documentum is
> by somehow designating groups as 'negative'. Is this correct?  Or are
> groups designated negative only within the context of individual ACLs?
>
>
>
> If groups themselves are negative, how do you know whether a group is
> negative?  Is there a way to do this in DQL?  And, can negative groups
> contain other groups?  Can groups in general contain other groups?
>
>
>
>
>
>
>
> I was not the original author of the Documentum connector and authority,
> and I do not have access to Documentum development materials at this time.
> It seems to me that the choice of access token for this connector was not
> well thought out, because instead of indexing the users and groups as is
> done for all other connectors, we need to resolve document visibility in
> the Documentum Authority.  But I can't reasonably change this now.  What I
> would like to try first is rewriting the Authority DQL based on what you
> can tell me about negative groups.
>
>
>
> Thanks,
>
> Karl
>
>
>
>
>
>
>
>
>
>
>
> On Wed, Apr 5, 2017 at 2:02 PM, Karl Wright <daddywri@gmail.com> wrote:
>
> Hi Sharnel,
>
>
>
> At the time the Documentum connector was created there was no such thing
> as a "deny" acl.
>
>
>
> I can supply a fix but I will need to know how to list "deny" acls for
> documentum documents, so if you could rewrite the above DQL query to return
> that list I can take it from there.
>
>
>
> Karl
>
>
>
>
>
> On Wed, Apr 5, 2017 at 1:40 PM, Sharnel Merdeck Pereira <
> spereire@worldbankgroup.org> wrote:
>
> Hi,
>
>
>
> We are having issues with authorization when there are negative acls.
>
>
>
> I have included an example below :
>
>
>
> ·         Indexing done using manifoldcf v 2.5, solr v 5.5.2
>
> ·         Indexed document with r_object_id 091e86d986f6a044
>
> ·         document has acl idocs_inst_540278_O_acl
>
> ·         acl idocs_inst_540278_O_acl has negative group added to it
> (r_accessor_name: emucw ; r_accessor_permit :1)
>
> ·         on indexing we see document has acl idocs_inst_540278_O_acl on
> allowed_token
>
> ·         user 000470248 has been added to group emucw
>
> ·         On querytime we get user having acl idocs_inst_540278_O_acl and
> user is able to see the document, *ideally there should not be access as
> negative group should take priority and should not be available in user acl*
> .
>
>
>
> I have attached screenshots and query logs:
>
>
>
>
>
> ·         User acls at query time
>
>
>
>
>
> ·         Query to fetch user acls in code :        SELECT DISTINCT
> A.owner_name, A.object_name FROM dm_acl A WHERE
>
>             A.object_name NOT LIKE 'dm_%' AND (
>
>             (any (A.r_accessor_name IN ('" + strAccessToken + "',
> 'dm_world') AND r_accessor_permit>2)
>
>             OR (any (A.r_accessor_name='dm_owner' AND
> A.r_accessor_permit>2) AND A.owner_name=" + quoteDQLString(strAccessToken)
> + ")
>
>             OR (ANY (A.r_accessor_name in (SELECT G.group_name FROM
> dm_group G WHERE ANY G.i_all_users_names = " +
> quoteDQLString(strAccessToken) + ")
>
>             AND r_accessor_permit>2)) )
>
>
>
>
>
>
>
> ·         Document values
>
>
>
>
>
>
>
>
>
> Kindly let me know if more details are required. How do I resolve above
> issue
>
>
>
>
>
> Thanks
>
> Sharnel
>
>
>
>
>
>
>

Mime
View raw message