Avoiding further (LDAP) stack proliferation in Samba

[Stefan Metzmacher]

Hi Andrew,

>>> That sounds like a sensible plan to me, but having said
>>> that I'm not going to be the one doing the work :-).
>>>
>>> As we as a community have decided tevent_req is "The Way"
>>> then helping our older stacks integrate better with it
>>> is certainly a good way to make progress IMHO (and I'm
>>> as guilty as anyone as the author of the horrible hack inside smbd
>>> to do async opens which sidesteps tevent_req in order
>>> to reduce code changes).
>>
>> So i am trying to understand where this leaves us. The driver behind
>> Swen's patchset is to move away from libads with the end goal of
>> being
>> able to better control the domain controller selection.
>>
>> Now there is tldap and ldb as possible ldap libraries. Do we need to
>> look at the integration of those components first, before adding the
>> ldap library usage in winbindd?
> 
> Yes.  I think so.  I know this sucks - being told to stop on a fairly
> simple change because we should do a much larger thing, but I'm really
> passionate to avoid having three full stacks. 

We already have and winbindd already uses tldap, so this is not adding
something new.

>> The goal of having one ldap client stack is worthwhile. From what i
>> can
>> see, tldap implements the async tevent model, with the exception of
>> the
>> gensec part. Also the async calls are currently not used.
>>
>> I have not looked in ldb much, on a quick look, it seems to use the
>> openldap library again. Would it make sense to have ldb use tldap as
>> backend and eventually move away from openldap?
> 
> While there is a historical OpenLDAP backend in LDB (a legacy from a
> time when being a semi-independent project was critical, possibly still
> used by sssd) Samba uses lib/ldb-samba/ldb_ildap.c for all ldap*://
> URLs, which is based on libcli/ldap.  This one brings in the full suite
> of GENSEC, Kerberos etc.
> 
> I'm not opposed to the concept that libcli/ldap and tldap are merged in
> some way and see particular opportunity for tldap to use the LDB
> structures (which would reduce further the code in ldb_ildap). 
> 
> For another approach, if the initial issues are around timing handling
> in the OpenLDAP libs under libads, significant advantage could come
> from rebasing libads on LDB.  libads is a sync API (and stuck at that
> for now) so the LDB sync API would be a good match.  Doing so would
> make things like our 'tls *' parameters work consistently for all our
> outbound TLS connections, which would be a big win. 
> 
> I realise this is not what you were hoping, but perhaps we can find a
> way forward here.

As you know I like the idea of having things implemented just once!
But as found out in the past this is a lot of work and
replacing everything at once is often not possible.
We learnt that we sometimes have to do small steps with intermediate
states, which we sometimes not like, but at the same time require
in order to make progress at all.

There're a lot of things I'd like to see:
1. The ldb api should not be used for pure LDAP users,
   it's bad enough that the strange async model exists at all!
   We should hope that it's only used for LDAP for command line
   tools in a sync fashion.
2. source3/lib/tldap_gensec_bind.c should use gensec_update_send/recv
3. tldap makes use of the "client ldap sasl wrapping" and other
   options, which are use by source4/libcli/ldap/ and
   source3/libads/
4. We can add some helpers to get/pass 'struct ldb_message' from/to
   tldap c.
5. users of source4/libcli/ldap/ should move to the tldap api
   - lib/ldb-samba/ldb_ildap.c can become lib/ldb-samba/ldb_tldap.c
6. libads should go away it, at least it's low level internals
   maybe it can be build on top of tldap as a first step in
   order to avoid a rewrite of all non-winbind users.
7. winbindd should avoid libads and only use tldap.

But the goal of
https://gitlab.com/samba-team/samba/-/merge_requests/1351
is moving along with 7.

And I'm not seeing why we would require 4, 5, 6 before doing 7.
They would be nice to have, but they tasks for another day.

BTW: I'm not saying that I'm happy with the current patchset of merge
request 1351. But that's a different discussion.

metze

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20200522/3d2b87dd/signature.sig>