Description of problem: "437525: GER: allow GER for non-existing entries" introduced a new type of list (e.g., "*@inetorgperson" "*@posixaccount") to the ldapsearch when the Get Effective Rights Control OID is given. If such list is given, a template entry is internally created and the effective rights are evaluated. Currently, the entry is not associated with any suffix. Therefore, no meaning ACIs are applied to the template entry. Since the search specifies the search base, we could use the dn as the template entry is located.
Created attachment 312947 [details] cvs diff ldap/servers/plugins/acl/acleffectiverights.c Description: get the target dn from the pblock and add it to the template entry dn if available. Plus a memory leak was found and fixed at the same time.
Created attachment 313006 [details] test ldif file This test sets ACI: aci: (target=ldap:///ou=Accounting,dc=example,dc=com)(targetattr="*")(version 3. 0; acl "tp25"; allow (read,search,compare) (userdn = "ldap:///anyone") ;) That is, no ACI in dc=example,dc=com, nor entries under ou other than ou=Accounting; entries under ou=Accounting,dc=example,dc=com have the permission rsc. Test cases: 1) search from dc=example,dc=com: $ ldapsearch -D "cn=Directory Manager" -w <pw> -b "dc=example,dc=com" -s base -J "1.3.6.1.4.1.42.2.27.9.5.2:false:dn: cn=Jacques SMITH, dc=example,dc=com" "(uidnumber=*)" "*@posixaccount" dn: cn=template_posixaccount_objectclass,dc=example,dc=com objectClass: posixaccount objectClass: top homeDirectory: dummy gidNumber: dummy uidNumber: dummy uid: dummy cn: dummy entryLevelRights: none attributeLevelRights: cn:none, uid:none, uidNumber:none, gidNumber:none, homeD irectory:none, objectClass:none, userPassword:none, loginShell:none, gecos:n one, description:none, aci:none 2) search from ou=accounting,dc=example,dc=com: $ ldapsearch -D "cn=Directory Manager" -w <pw> -b "ou=accounting,dc=example,dc=com" -s base -J "1.3.6.1.4.1.42.2.27.9.5.2:false:dn: cn=Jacques SMITH, dc=example,dc=com" "(uidnumber=*)" "*@posixaccount" dn: cn=template_posixaccount_objectclass,ou=accounting,dc=example,dc=com objectClass: posixaccount objectClass: top homeDirectory: dummy gidNumber: dummy uidNumber: dummy uid: dummy cn: dummy entryLevelRights: v attributeLevelRights: cn:rsc, uid:rsc, uidNumber:rsc, gidNumber:rsc, homeDirec tory:rsc, objectClass:rsc, userPassword:rsc, loginShell:rsc, gecos:rsc, desc ription:rsc, aci:rsc 3) search from ou=payroll,dc=example,dc=com: $ ldapsearch -D "cn=Directory Manager" -w <pw> -b "ou=payroll,dc=example,dc=com" -s base -J "1.3.6.1.4.1.42.2.27.9.5.2:false:dn: cn=Jacques SMITH, dc=example,dc=com" "(uidnumber=*)" "*@posixaccount" dn: cn=template_posixaccount_objectclass,ou=payroll,dc=example,dc=com objectClass: posixaccount objectClass: top homeDirectory: dummy gidNumber: dummy uidNumber: dummy uid: dummy cn: dummy entryLevelRights: none attributeLevelRights: cn:none, uid:none, uidNumber:none, gidNumber:none, homeD irectory:none, objectClass:none, userPassword:none, loginShell:none, gecos:n one, description:none, aci:none 4) search from "" (no acis are set): ldapsearch D "cn=Directory Manager" -w <pw> -b "" -s base -J "1.3.6.1.4.1.42.2.27.9.5.2:false:dn: cn=Jacques SMITH, dc=example,dc=com" "(uidnumber=*)" "*@posixaccount"version: 1 dn: cn=template_posixaccount_objectclass, objectClass: posixaccount objectClass: top homeDirectory: dummy gidNumber: dummy uidNumber: dummy uid: dummy cn: dummy entryLevelRights: none attributeLevelRights: cn:none, uid:none, uidNumber:none, gidNumber:none, homeD irectory:none, objectClass:none, userPassword:none, loginShell:none, gecos:n one, description:none, aci:none
Created attachment 313120 [details] cvs diff ldap/servers/plugins/acl/acleffectiverights.c Following the suggestion from Nathan, the "dummy" attributes are replaced with "(template_attribute)". Sample result: $ ldapsearch -D "uid=TVradmin0, ou=Accounting, dc=example,dc=com" -w TVradmin0 -b "ou=accounting,dc=example,dc=com" -s base -J "1.3.6.1.4.1.42.2.27.9.5.2:false:dn: uid=TVradmin0, ou=Accounting, dc=example,dc=com" "(uidnumber=*)" "*@posixaccount" version: 1 dn: cn=template_posixaccount_objectclass,ou=accounting,dc=example,dc=com objectClass: posixaccount objectClass: top homeDirectory: (template_attribute) gidNumber: (template_attribute) uidNumber: (template_attribute) uid: (template_attribute) cn: (template_attribute) entryLevelRights: v attributeLevelRights: cn:rsc, uid:rsc, uidNumber:rsc, gidNumber:rsc, homeDirec tory:rsc, objectClass:rsc, userPassword:rsc, loginShell:rsc, gecos:rsc, desc ription:rsc, aci:rsc
Created attachment 313121 [details] cvs commit message Thanks to Nathan for his reviews and suggestions! Checked in into CVS HEAD.
Noticed one flaw. When an empty string "" (rootdse) is the search base dn, "," is added to the template objectclass rdn, which should not be. $ ldapsearch -D "cn=Directory Manager" -w Secret123 -b "" -s base -J "1.3.6.1.4.1.42.2.27.9.5.2:false:dn: uid=tuser0, ou=Accounting, dc=example,dc=com" "(uidnumber=*)" "*@posixaccount" version: 1 dn: cn=template_posixaccount_objectclass, <== objectClass: posixaccount objectClass: top homeDirectory: (template_attribute) gidNumber: (template_attribute) uidNumber: (template_attribute) uid: (template_attribute) cn: (template_attribute) entryLevelRights: none attributeLevelRights: cn:none, uid:none, uidNumber:none, gidNumber:none, homeD irectory:none, objectClass:none, userPassword:none, loginShell:none, gecos:n one, description:none, aci:none
Created attachment 313136 [details] cvs diff ldap/servers/plugins/acl/acleffectiverights.c Not just checking if dn is NULL or not, but also checking the length of dn is greater than 0. If both conditions are satisfied, locate the template entry at the dn.
Created attachment 313137 [details] cvs commit message Checked in into CVS HEAD.
Created attachment 313854 [details] diffs - memory leaks
Thanks, Rich, for finding out the leaks.
AFAICT, the leaks can be triggered by an anonymous search. The leaks can be mitigated by disabling anonymous search, but some applications may not be able to do that.
Created attachment 313980 [details] cvs commit log - mem leaks Reviewed by: nhosoi (Thanks!) Fix Description: There are a couple of memory leaks in the code. acleffectiverights.c line 617 calls slapi_attr_get_valueset to get the list of objectclass values in objclassvals - this function allocates memory (returns a dup of the list) but this is not freed. The fix is to call slapi_valueset_free() to free it. The allattrs and opattrs arrays are not freed in all conditions. The fix is to make sure they are freed in all conditions. Platforms tested: RHEL5, Fedora 8 Flag Day: no Doc impact: no
verified RHEL 5 DS 8.1 test 1: [root@jennyv2 457156]# /usr/lib/mozldap/ldapsearch -D "cn=Directory Manager" -w Secret123 -b "dc=example,dc=com" -s base -J "1.3.6.1.4.1.42.2.27.9.5.2:false:dn: cn=Jacques SMITH, dc=example,dc=com" "(uidnumber=*)" "*@posixaccount" version: 1 dn: cn=template_posixaccount_objectclass,dc=example,dc=com objectClass: posixaccount objectClass: top homeDirectory: (template_attribute) gidNumber: (template_attribute) uidNumber: (template_attribute) uid: (template_attribute) cn: (template_attribute) entryLevelRights: none attributeLevelRights: cn:none, uid:none, uidNumber:none, gidNumber:none, homeD irectory:none, objectClass:none, userPassword:none, loginShell:none, gecos:n one, description:none, aci:none test 2: [root@jennyv2 457156]# /usr/lib/mozldap/ldapsearch -D "cn=Directory Manager" -w Secret123 -b "ou=accounting,dc=example,dc=com" -s base -J "1.3.6.1.4.1.42.2.27.9.5.2:false:dn: cn=Jacques SMITH, dc=example,dc=com" "(uidnumber=*)" "*@posixaccount" version: 1 dn: cn=template_posixaccount_objectclass,ou=accounting,dc=example,dc=com objectClass: posixaccount objectClass: top homeDirectory: (template_attribute) gidNumber: (template_attribute) uidNumber: (template_attribute) uid: (template_attribute) cn: (template_attribute) entryLevelRights: v attributeLevelRights: cn:rsc, uid:rsc, uidNumber:rsc, gidNumber:rsc, homeDirec tory:rsc, objectClass:rsc, userPassword:rsc, loginShell:rsc, gecos:rsc, desc ription:rsc, aci:rsc test:3 [root@jennyv2 457156]# /usr/lib/mozldap/ldapsearch -D "cn=Directory Manager" -w Secret123 -b "ou=payroll,dc=example,dc=com" -s base -J "1.3.6.1.4.1.42.2.27.9.5.2:false:dn: cn=Jacques SMITH, dc=example,dc=com" "(uidnumber=*)" "*@posixaccount" version: 1 dn: cn=template_posixaccount_objectclass,ou=payroll,dc=example,dc=com objectClass: posixaccount objectClass: top homeDirectory: (template_attribute) gidNumber: (template_attribute) uidNumber: (template_attribute) uid: (template_attribute) cn: (template_attribute) entryLevelRights: none attributeLevelRights: cn:none, uid:none, uidNumber:none, gidNumber:none, homeD irectory:none, objectClass:none, userPassword:none, loginShell:none, gecos:n one, description:none, aci:none test 4: [root@jennyv2 457156]# /usr/lib/mozldap/ldapsearch -D "cn=Directory Manager" -w Secret123 -b "" -s base -J "1.3.6.1.4.1.42.2.27.9.5.2:false:dn: cn=Jacques SMITH, dc=example,dc=com" "(uidnumber=*)" "*@posixaccount"version: 1 dn: cn=template_posixaccount_objectclass objectClass: posixaccount objectClass: top homeDirectory: (template_attribute) gidNumber: (template_attribute) uidNumber: (template_attribute) uid: (template_attribute) cn: (template_attribute) entryLevelRights: none attributeLevelRights: cn:none, uid:none, uidNumber:none, gidNumber:none, homeD irectory:none, objectClass:none, userPassword:none, loginShell:none, gecos:n one, description:none, aci:none
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on therefore solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHEA-2009-0455.html