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 > > > > > > >
