Avoiding further (LDAP) stack proliferation in Samba

Andrew Bartlett abartlet at samba.org
Wed May 20 23:47:50 UTC 2020


G'Day Sswen and Christian,

As this is a more 'meta' question, I wanted to write to the broader
mailing list in regard to: 
https://gitlab.com/samba-team/samba/-/merge_requests/1351#note_346327256
which is following on from Jermey's comment: https://gitlab.com/samba-team/samba/-/merge_requests/1258#note_320352109

I'm really sorry this discussion has come up on what might, in other
circumstances been a great demonstration of showing the broader design
that started the tldap changes.

Jermey asked earlier to see the broader designs and given the broader
implications I think it is appropriate to have that raised on the list
here.  

Explaining our plans in public before we have code is not something we
do well in Samba - we fear (and this mail shows that is a genuine fear)
that others will jump in and suggest things.  Much easier to have the
code finished and put any questions to bed with: well, this is written
and works!

However, I quite strongly feel that we should not further proliferate
the new or substantial new use of tldap in Samba without:
 - offsetting work to reduce, not increase the number of LDAP protocol
stacks
and
 - substantial sharing of structures, ASN.1 parsing and other utility
code

My preference, as these are all sync or local callback based calls is
that you implement this with LDB.  LDB is a mature, extensively used
LDAP client library (not just the directory store for the AD DC).  

The routines you would need are ldb_search() and ldb_request().  The
timeout can be easily set on each request and I can assist with further
guidance if need be.

It might be that LDB as a whole is not suitable.  If so then I would
ask you instead implement other offsetting measures between all our
LDAP client libs.

We have seen in many other areas of Samba the incredible cost of code
duplication.  The efforts needed to merge the s3 and s4 RPC stacks has
been monumental.  The gap between the s3 and s4 loadparm systems
continues to create headaches that make it significantly harder than it
should be to just select and use the best of Samba's library code!

We have also seen this done well, where the new better API is
introduced on the basis that it also provide an emulation for and often
eventual elimination of the old API.  As examples:
 - Andreas introduced a new set of macros (PULL_LE_U32 et al) for
reading and writing integers, and the old macros (SIVALX et al) use
those.  The NDR callers have already been converted.
 - The python3 comparability API was introduced for the py2/py3
transition and is now almost totally removed.
 - gensec wrapped the old source3 authentication code first as a 'no
change' and then slowly the parts under it were merged.
 - the datagram messaging system is now common, underpinning both
messaging APIs.

You might ask why I didn't make this comment in 2015 when the idmap_ad
code was written, and why that prior art isn't a good enough guide?

I'll just say that the history of LDB in the Samba Team has been
fraught, and it would not have been wise of me to make a criticism to
those involved, at that time.

But I must raise this now, before we end up with three fully-fledged
LDAP client stacks in Samba!

Andrew Bartlett
-- 
Andrew Bartlett                       https://samba.org/~abartlet/
Authentication Developer, Samba Team  https://samba.org
Samba Developer, Catalyst IT          
https://catalyst.net.nz/services/samba






More information about the samba-technical mailing list