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

[ando@sys-net.it]

On Wed, 2006-05-31 at 11:35 +0200, Michail Bachmann wrote:

> > That's what I mean: consistent with libldap.
> 
> Sure, but then what would you need the chain overlay for?

Well,  for clients that don't understand referrals, of course.  Sounds
like a catch 22, but slapo-chain should chase referrals instead of the
client except when it's not possible.  In those cases, returning the
referral in general is the most appropriate thing to do.  See below.

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

You're making an incorrect assumption here: ACLs on the slave are not
checked at all, since the frontend detects a write to a shadow database
and returns the referral __before__ even getting to access control.
That's why the real reason of the failure isn't detected in advance by
the slave.  Note that here you assume the slave has exactly the same
ACLs of the master, which may not be correct and, in general, it's a bad
assumption, since the slave is a shadow of the master and thus does not
own the data it's presenting.

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

Correction: only the master checks access and rejects the modification.
Note that in principle the master and the slave should have exactly the
same permissions up to "read", while "write" on the slave should only be
allowed for the "updatedn".  Exposing a referral to the master, in
general, is still the best thing a smart-but-not-smarter server can do,
because the only way to solve the issue consists in directly writing to
the master and find out why it didn't work.

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

No, I'm just saying that what you find reasonable may not be as
reasonable for others, while in general things out of specifications
seemed reasonable at least to a fair amount of competent people (note
that I'm not saying you're not!).

After the explanation of what you intend to do, your request seems
pretty reasonable, provided it qualifies as an exceptional behavior to
be used for that specific case.  Slapo-chain originated from some
requirement I'm not aware of in OpenLDAP 2.2 and, as such, couldn't be
used to do what you're using it for, i.e. allow slaves as transparent
write entry points.  This became possible only after I added support for
global overlays in OpenLDAP 2.3 (and that was the essential reason I
added that support), so what you call the "most simple and needed use"
actually came into mind and became possible only one minor version after
slapo-chain was introduced.  Moreover, as it appears from not-so-recent
discussion in openldap-devel, slapo-chain is still an incomplete answer
to distributed directories since it lacks a decent implementation of
distributed operations.  Note that in HEAD you'll find the skeleton of
an implementation of draft-sermersheim-ldap-distproc which will
eventually complement (and partially obsolete) slapo-chain, but that's
really an empty box right now.

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

Well, basically I believe that clients that are controls-aware, and thus
capable of sending that control, should be smart enough to be able to
handle referrals themselves.  I agree it is a completely different
matter if the control is used by slapo-chain itself to control how
hidden referral chasing occurs, but it would still be a partial solution
to your problem, because in case of error the referred DSA would return
"cannotChain" instead of the real error.

Believe me: the only solution would be to implement some form of
distributed operation, so that the original operation is wrapped into
the distributed exop, and slapo-distproc sees the error return of the
exop, unwraps the response and sends the right error to the client much
like as if the operation really occurred locally.

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

The change you seem to envisage may or may not be suitable for the
general usability of slapo-chain.  Feel free to submit it as a patch
(I'll take this ITS as a feature enhancement request), but I feel it
should be specific, i.e. not the default, and clearly marked as a
workaround for the specific usage you described above, while we wait for
an implementation of distributed procedures.

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