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

Re: Circular referral (Was: (ITS#4055) back-ldap hangs)

Pierangelo Masarati wrote:
[moved to -devel for discussion]

On Fri, 2005-09-30 at 18:39 +0000, raphael.ouazana@linagora.com wrote:
Finally I think it is a configuration problem : a special case of
recursive referral.
I think you can close this ITS or change it in a feature request to detect
this special bad configuration :
Server 1 with back-ldap pointing to server 2.
Server 2 with back-bdb with a referral to server1.

I think we need to design some procedure to detect this type of issues. In fact, now that back-ldap is being used for a number of applications that may give rise to circular referral conditions (proxy, chain, ...), the referral mechanism appears somewhat inadequate. In fact, it doesn't allow a built-in and standardized way to keep track of its history and/or at least count. While this might be food for thought for the ldapbis list, the current implementation of the proxy and of the chain overlay would really need this. For example, the current implementation of the chain overlay violates draft-ietf-ldapbis-protocol where it states

   Clients that follow referrals MUST ensure that they do not loop
   between servers. They MUST NOT repeatedly contact the same server for
   the same request with the same parameters. Some clients use a counter
   that is incremented each time referral handling occurs for an
   operation, and these kinds of clients MUST be able to handle at least
   ten nested referrals while progressing the operation.

because in this case it is __not__ the client library that follows
referrals and counts the number of referrals that have been followed
(thus limiting recursion by limiting the maximal count of referrals
chased, instead of keeping track of the values that were chased).  With
back-ldap and with proxies in general, there is no way to determine if a
request comes as a consequence of a referral chasing.

Maybe we could add some sort of control that appends a cookie to
requests and instructs the server to propagate that cookie when chasing
referrals or proxying the request. The appearance of the cookie in a
request to a server, when the cookie originated from that server for
that very request, would indicate a circular reference. I think there
is more to think about this (servers that do not implement this control
would destroy its usefulness; we need a specific control to implement
something that should be granted anyway according to draft-ietf-ldapbis-
protocol; each sub-request performed to satisfy the initial one would
need to be appended to the cookie because the circular reference may
start at any level of nested request; ...).
Just more evidence of the poor design choices that we're stuck with in LDAP; trying to use a client-server protocol for server-server operations is always going to run into this type of problem. And referrals in general have always been a weak spot in the LDAP design.

I think you may be able to attach a cookie to the request by adding an item to the search filter. Yes, this is a hack, but obviously you need something that works today, and this should work without breaking anything else.

 -- Howard Chu
 Chief Architect, Symas Corp.  http://www.symas.com
 Director, Highland Sun        http://highlandsun.com/hyc
 OpenLDAP Core Team            http://www.openldap.org/project/