[Fedora-directory-devel] Please review: [Bug 457156] GER: allow GER for non-existing entries (phase 2)

[Noriko Hosoi]

https://bugzilla.redhat.com/show_bug.cgi?id=457156

           Summary: GER: allow GER for non-existing entries (phase 2)
           Product: Fedora Directory Server
           Version: 1.1.1
          Platform: All
        OS/Version: Linux
            Status: NEW
          Severity: low
          Priority: low
         Component: Security - Access Control (GER)
        AssignedTo: nhosoi at redhat.com
        ReportedBy: nhosoi at redhat.com
         QAContact: ckannan at redhat.com
   Estimated Hours: 0.0

The change is too small for "(phase 2)", though... :)

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.

------- Additional Comments From nhosoi at redhat.com  2008-07-29 19:05 EST -------
Created an attachment (id=312947)
 --> (https://bugzilla.redhat.com/attachment.cgi?id=312947&action=view)
cvs diff ldap/servers/plugins/acl/acleffectiverights.c

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

------- Additional Comments From nhosoi at redhat.com  2008-07-30 11:29 EST -------
Created an attachment (id=313006)
 --> (https://bugzilla.redhat.com/attachment.cgi?id=313006&action=view)
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



-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3237 bytes
Desc: S/MIME Cryptographic Signature
Url : http://lists.fedoraproject.org/pipermail/389-devel/attachments/20080730/96b889ac/attachment.bin