Re: Problem in acl.c

["Kurt D. Zeilenga" <Kurt@OpenLDAP.org>]

ACL's and proxies are fun.  I think one needs to choose:
        a) remote server enforces access controls
        b) proxy enforces access controls

In either case, what the proxy returns to the client must
be consistent with RFC 2251:
   Servers which perform caching or shadowing MUST ensure that they do
   not violate any access control constraints placed on the data by the
   originating server.

Kurt

At 02:20 PM 5/6/01, Pierangelo Masarati wrote:
>Kurt,
>
>I've a problem with the logics of acl matching when using back-ldap.
>It is not a big, big deal because it is triggered by very special
>conditions, however there it is.
>When checking for the subject clause "dnattr=<attr>", the <attr> is
>looked up in the entry, and its values are compared to the normalized
>value of the operation dn (see servers/slapd/acl.c line 685).
>This assumes that the ENTIRE entry is available
>when the comparison is made. However, when the back-ldap is used,
>only the portion of entry that was requested is currently available
>when processing the acl. Imagine I protected the "cn" of an entry
>with the clause "dnattr=member":
>
>access to dn="cn=my entry,dc=my,dc=domain" attr=cn
>        by dnattr=member read
>        by * none
>
>and the entry reads:
>
>dn: cn=my group,dc=my,dc=domain
>objectClass: top
>objectClass: groupOfNames
>cn: my group
>member: cn=my group,dc=my,dc=domain
>member: cn=someone else,dc=my,dc=domain
>
>while I'm performing the query:
>
>ldapsearch -D 'cn=someone else,dc=my,dc=domain' -w secret \
>        -b 'cn=my group,dc=my,dc=domain' -s base cn
>dn: cn=my group,dc=my,dc=domain
>
>then the back-ldap asks the real DS only the "cn" attribute, and, at acl
>checking, it doesn't find the "member" attribute so the check fails,
>even if "someone else" has access to the "cn". In fact, if the member
>attribute is also required (or all the attrs are required), the acl
>succeedes:
>
>ldapsearch -D 'cn=someone else,dc=my,dc=domain' -w secret \
>        -b 'cn=my group,dc=my,dc=domain' -s base cn member
>dn: cn=my group,dc=my,dc=domain
>cn: my group
>member: cn=my group,dc=my,dc=domain
>member: cn=someone else,dc=my,dc=domain
>
>In case the attr is not found in the entry, the entry should be read
>again with the <attr> of the "dnattr" explicitly required. Or, to
>avoid excessive overhead for other backends, this should happen in case
>the backend provides a method to reload the entry specifically
>requiring an attribute. I've noticed this is done by the method 
>"backend_attribute", but I haven't been able to track the point where
>it is called (the acl stuff is really cumbersome!), and it is
>definitely NOT called in the case I discussed above.
>
>Any clues/ideas/suggestions?
>
>Pierangelo.