Avoiding further (LDAP) stack proliferation in Samba

Andrew Bartlett abartlet at samba.org
Thu Jun 25 04:09:17 UTC 2020

On Wed, 2020-06-24 at 12:22 +0200, Stefan Metzmacher wrote:
> Can you agree on that plan?
> If so we can start working on this without running into a deadlock
> again.

Sounds like a plan.

I also agree that touching smbldap itself is quite risky, I had hoped a
way out of smbldap would be via deprecation and removal of the callers,
but it seems we will have these for a while yet.

Splitting ldap_message.c into client and server would be useful for
many good reasons (we decode client messages on the server right now,
before rejecting them). 

I just hope that we can agree to allow (dare I say encourage) AD client
code to use the LDB and LDB-adjacent utility functions for the above-
LDAP parsing (DN, Extended DN, GUID, SID, etc).  This stuff looks so
simple until you read ads_parent_dn() and cry...

Finally, I wanted to say a big thank you to you and everyone else for
taking the time to understand my concerns, I think we are in much more
agreement now.


Andrew Bartlett

Andrew Bartlett
Authentication Developer, Samba Team         https://samba.org
Samba Development and Support, Catalyst IT - Expert Open Source

More information about the samba-technical mailing list