tevent_abort_nesting crash in idmap_ad

Volker Lendecke vl at samba.org
Sat Jun 25 06:37:40 UTC 2016

On Fri, Jun 24, 2016 at 08:28:08PM -0700, Jeremy Allison wrote:
> You said "but it's pointless and inefficient to go through a _send/_recv
> pair when we have a sync routine deeply inside."
> But that's what the code is *already* doing. The idmap_ad is
> calling the sync version of tldap bind, not the async version,
> All current callers are sync. If you want to make the _send/_recv
> versions static so tldap only exposes the sync version of
> the gensec bind, that's also an option to remove the issue
> of having a sync call inside an async pair.

It's one thing to use the sync wrappers. We have a *lot* of code doing
that. It's another thing to offer an async API that has no chance to
actually deliver what it promises to do -- asynchrony.

I've talked to Love many years ago about async GSSAPI and he said he
would need it for Apple.  Do you want us to wait for that to go into
heimdal and then through the standards bodies into MIT too? We're
talking a decade *if* it will ever happen given the current focus on
releases heimdal has right now. Also, putting the kinit into a
helper thread will reveal so many bugs in libkrb5 that people will
run away and the "winbind rpc only" setting will become very important
again to prevent any krb5 use, like it was when it was put in

> Now this doesn't become urgent as it's master-only right now,
> but I'd like to add this fix into master until you have the
> time to fix it using the OpenLDAP API, or someone fixes the
> gensec SPNEGO to be fully async. Currently the code can crash,
> and that's bad.

The revert is just as simple. It also fixes the crash it just as

tldap was already rejected once in the past by the AD developers because
in the AD world linking everything together using direct ldb access is
the technically superior solution.  I should have learned my lesson
back then that tldap is just not the direction the Samba project is
heading. So it needs to leave, now that we have found another road block
that is not practical to remove.


More information about the samba-technical mailing list