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

[michail.bachmann@cms.hu-berlin.de]

On Tuesday 30 May 2006 19:30, Pierangelo Masarati wrote:
> > 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.

Sure, but then what would you need the chain overlay for?

> >> 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?

Maybe we operate on different assumptions what this overlay can be used for. 
See below for my a description what I use it for.

> > 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.

I think we just have different opinions on how smart the server should 
be... ;-)

> >> 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?

My use case: single master, multiple slaves with updateref pointing to the 
master. Clients should always connect to the slaves, never to the master. The 
clients are mostly read, sometimes write. Now any write is forwarded to the 
master through the chain overlay and with the help of proxyauthz the server 
knows the real dn of the client. Unfortunately (for me) *every* write is 
forwarded to the master, even if the acls on the slave said they would 
prohibit the write anyway. Now the master checks the same acls and 
returns "insufficient permission" to the slave, which (instead of forwarding 
the error message to the client) exposes the internal referral.

> > 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).

Maybe I miss something, but why must there be a specification for the most 
simple (and most needed?) case? I think a single configurable change in the 
behaviour of the chain overlay would ease such deployments as mine 
tremendousely.

> >> 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.

Can you elaborate on that? Except that it is pretty slim, why is it not 
usefull?

> 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.

I can do that, but maybe there is a more simple change.

Mit freundlichen Gruessen / Kind regards

Michail Bachmann

-- 
ZE Computer- und Medienservice der Humboldt-Universitaet zu Berlin
phone: +49.30.2093.2191
Raum 1064b, Unter den Linden 6, D-10099 Berlin, Germany