Hi Sharnel, I've attached a patch to the CONNECTORS-1401 ticket. Please let me know if it works for you.
Thanks, Karl On Thu, Apr 6, 2017 at 5:52 PM, Karl Wright <[email protected]> wrote: > 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 < > [email protected]> 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:[email protected]] >> *Sent:* Thursday, April 06, 2017 2:49 AM >> *To:* [email protected] >> *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 <[email protected]> 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 < >> [email protected]> 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 >> >> >> >> >> >> >> > >
