[Date Prev][Date Next]
Re: Circular referral (Was: (ITS#4055) back-ldap hangs)
Pierangelo Masarati wrote:
Actually I don't see this as a problem for referral processing, though
we have to change how we handle it. That is, the back-ldap proxy needs
to check when it receives a referral, and see if the referral points to
itself, before chasing it. In the case of chaining, where the remote
server progresses the request itself, the chaining control would be
used. Unfortunately the Sermersheim draft has expired, and anyway that
control doesn't carry enough information to solve this problem. Someone
needs to go back to the X.518 ChainingArguments and at least bring the
traceInformation into the LDAP chaining control spec.
[moved to -devel for discussion]
On Fri, 2005-09-30 at 18:39 +0000, firstname.lastname@example.org wrote:
Finally I think it is a configuration problem : a special case of
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
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; ...).
-- 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/