[PATCH v2 7/7] wldap32: supply SASL credentials in a mechanism-specific form

[Damjan Jovanovic]

So far it appears that SASL mechanisms require credentials supplied
to them in a mechanism-specific form.

OpenLDAP's ldap_sasl_interactive_bind() passes the caller-supplied
rmech to ldap_int_sasl_bind() in libraries/libldap/cyrus.c.
There, it is populated from the chosen authentication mechanism
(mech) returned by sasl_client_start(), before calling the interact()
callback. By providing rmech to our sasl_interact() callback, it can
know which SASL mechanism it is supplying credentials for, and can
supply them in a mechanism-specific form.

Hans reported GSSAPI and GSS-SPNEGO want an empty AUTH_CB_USER.
I verified DIGEST-MD5 wants AUTH_CB_AUTHNAME and doesn't mind if
AUTH_CB_USER is supplied. Dmitry reported that for his mechanism
(some variation of Kerberos?) AUTH_CB_AUTHNAME is used for initial
tickets but AUTH_CB_USER is mandatory thereafter. This patch should
hopefully make all those mechanisms happy.

Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=50572
Signed-off-by: Damjan Jovanovic 
---
 dlls/wldap32/bind.c | 65 ++++++++++++++++++++++++++++++++++++++++-----
 1 file changed, 58 insertions(+), 7 deletions(-)

[Marvin]

Hi,

While running your changed tests, I think I found new failures.
Being a bot and all I'm not very good at pattern recognition, so I might be
wrong, but could you please double-check?

Full results can be found at:
https://testbot.winehq.org/JobDetails.pl?Key=85537

Your paranoid android.

=== debiant2 (32 bit report) ===

wldap32:
Unhandled exception: page fault on read access to 0x00000000 in 32-bit code (0x7e9b6a2e).

=== debiant2 (32 bit Chinese:China report) ===

wldap32:
Unhandled exception: page fault on read access to 0x00000000 in 32-bit code (0x7e92ca2e).

=== debiant2 (32 bit WoW report) ===

wldap32:
Unhandled exception: page fault on read access to 0x00000000 in 32-bit code (0x7e9b6a2e).

=== debiant2 (64 bit WoW report) ===

wldap32:
Unhandled exception: page fault on read access to 0x00000000 in 32-bit code (0x7e9b6a2e).

[Dmitry Timoshkov]

Damjan Jovanovic  wrote:
> Hans reported GSSAPI and GSS-SPNEGO want an empty AUTH_CB_USER.
> I verified DIGEST-MD5 wants AUTH_CB_AUTHNAME and doesn't mind if
> AUTH_CB_USER is supplied. Dmitry reported that for his mechanism
> (some variation of Kerberos?) AUTH_CB_AUTHNAME is used for initial
> tickets but AUTH_CB_USER is mandatory thereafter. This patch should
> hopefully make all those mechanisms happy.

There's some miscommuniation here it seems, I don't see AUTH_CB_AUTHNAME
in the callback at all. I'd still suggest simply add AUTH_CB_AUTHNAME as
an alias for existing AUTH_CB_USER and don't add any code for mechanisms.