RE: back-dnssrv

["Pierangelo Masarati" <ando@sys-net.it>]

> I think we need to find out how an uninitialized SlapReply found its way
> into this search function. That should cause problems for all the code,
> not just back-dnssrv/search.c. Setting rs->sr_ref to NULL here is only
> masking the real bug.

Possibly it was back-dnssrv itself which didn't clear out
the sr_ref after issuing the default referral; now I've
fixed it.  Maybe Luke can try to track it down and check
if it works now?  I think I'll do an audit of the backends
and clear out all entries in SlapReply right after they're
used (I just did it in back-monitor and back-dnssrv :).

>
>> I note that the compare
>> function also asserted manageDSAit, but it is not set in the
>> bi_info structure because it's not implemented; I don't know
>> if it'll ever be useful, so I don't think we need to implement it.
>
> Right, I have no idea what was ever intended for it. If it's never going
> to be implemented we should just cvs rm the file. Kurt?
>
>> I'd also like to integrate back-dnssrv into back-ldap, so that
>> it can be configured with (empty?) suffix and default uri, and
>> try to resolve the actual URI, but chasing the referral on behalf of
>> the client, resorting to the default URI in case of no match.
>
>> Maybe this operation might be stacked on top of back-ldap ...
>
> Sounds like a good approach. But there are security considerations here
> as far as how the referral should be chased. Since dnssrv can return a
> referral to basically any LDAP server in the world, we should never use
> the current "rebind-as-user" code. The chain config should have a set of
> URIs for which mutual trust exists, with credentials for binding to each
> of them. Any other URIs are by definition untrusted, and should be
> chased anonymusly.

Right.  This might be part of a proxy auth policy
which other backends may benefit from when chasing
referrals.

p.

-- 
Pierangelo Masarati
mailto:pierangelo.masarati@sys-net.it