Re: (ITS#4570) slapo-chain does not return an error when chasing a referral fails

[ando@sys-net.it]

> On Tuesday 30 May 2006 17:53, Pierangelo Masarati wrote:
>> > When the chain overlay encounters an error while chasing a referral it
>> > will
>> > return the chased referral to the client instead of the occured error.
>>
>> This behavior is consistent with that of libldap, and I believe it is
>> desirable.
>
> Unfortunately it is inconsistent: You get the correct behaviour if
> everything
> went all right, but not the real error message if something went wrong. In
> fact you fall back to the behaviour of libldap which IMO minimizes the
> usefullness of this overlay.

That's what I mean: consistent with libldap.

>> In fact, slapo-chain tries to chain operations when possible;
>> when it's not, the referral is returned to the client under the
>> assumption
>> the client may know how to deal with referrals that couldn't be
>> automatically chased.
>
> It is this assumption I find questionable. Often the server is in a much
> better position (e.g. proxy or slave) to chase the referral,

How can the server work around the fact that a client contacted it without
even suspecting that its request was being redirected somewhere else, and
that the identity used by the client, although valid for use in that
server would have not enough permissions when the operation gets chained?

> especially as
> very few clients actually implement referral chasing.

You can't blame a server for client's flaws.  You pretend that the server
behaves smarter that reasonable because clients are too dumb?  I agree the
server should be smarter that clients and, in general, as smart as
possible, but nothing more that that.

>> This is true, for example, in cases where a
>> referral needs to be chased with an identity that differs from that used
>> for the original request, and I guess this is your case: slapo-chain is
>> receiving an "inusufficientAccess" code.
>> Or maybe you need to use the "idassert" feature so that the identity
>> your
>> client bound with is asserted while chasing the referral by means of the
>> proxyAuthz control (RFC4370); see slapd-ldap(5) for details.
>
> I am already using it. But because the ACLs are not checked before chasing
> the
> referral

I'm not sure I get this sentence; can you explain?  What ACLs should be
checked before chasing the referrals, and by who?

> and the actual error message is not returned, this overlay is not
> as
> usefull as I thought at first.

It might not be as useful as you expect it to be, since you seem to expect
it to foresee what it can't.  Maybe a well-defined operation chaining
could do what you ask for.  But I'd note that operation chaining, although
being tremendously needed (for example by you, but by me as well) is still
lacking specifications (see for example the expired
<draft-sermersheim-ldap-distproc> and X.518).

>> If you need a different behavior, e.g. that no referrals ever get
>> returned, you may want to look into using the "chainingBehavior" control
>> <draft-sermersheim-ldap-chaining> (expired), which is implemented in
>> slapo-chain(5).  The code might be a little bit broken as it's never
>> been
>> revitalized after the draft expired.
>
> Yes, I have already looked into it. Is it foreseeable whether this control
> will stay or are there plans to remove it?

Well, since the specification expired and it didn't look extremely useful,
I don't see any pressure in maintaining it.  I don't see any reason to
remove it, though.  If you find it useful, and you like to spend some time
in testing and debugging it, this might be the right opportunity to
revitalize that code.

p.



Ing. Pierangelo Masarati
Responsabile Open Solution
OpenLDAP Core Team

SysNet s.n.c.
Via Dossi, 8 - 27100 Pavia - ITALIA
http://www.sys-net.it
------------------------------------------
Office:   +39.02.23998309          
Mobile:   +39.333.4963172
Email:    pierangelo.masarati@sys-net.it
------------------------------------------