[Date Prev][Date Next] [Chronological] [Thread] [Top]

RE: Problem in acl.c



> -----Original Message-----
> From: owner-openldap-devel@OpenLDAP.org
> [mailto:owner-openldap-devel@OpenLDAP.org]On Behalf Of Kurt D. Zeilenga

> 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 a guess, the remote server does whatever it does, regardless of who
calls it. That means (a) is always true (unless the remote server has
explicitly turned controls off). The question then is whether you should
do (b) as well or not.

If you want to handle all of these cases of missing attributes, I
suggest that back-ldap should walk through the backend-specific ACLs
looking for all referenced attrs and add them to the attribute list
before passing on the search.

Realize though that you're out of luck in evaluating ACLs on modify
operations, unless you are going to do a fetch first. I suppose you could
take the position that one would never modify an entry that one hasn't
looked at recently, and try caching search results.

  -- Howard Chu
  Chief Architect, Symas Corp.       Director, Highland Sun
  http://www.symas.com               http://highlandsun.com/hyc  
> 
> 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.
>