Workaround bugs exposed by test_context changes

Bugs exposed by 61720a0:

 - test_context --client-name=... --mech-type=ntlm ... fails;

 - gss_acquire_cred() with desired_mech=NTLM and
   desired_name==GSS_C_NO_NAME fails;

 - gss_init_sec_context() with non-default cred handle calls the
   mechanism even when the given cred handle has no element for the
   requencet mechanism.

tests/gss/check-ntlm works by accident: gss_acquire_cred() with
desired_mechs==GSS_C_NO_OID_SET succeeds mostly because there are
Kerberos credentials available, and then the subsequent
gss_init_sec_context() call works because of the third bug described
above.
This commit is contained in:
Nicolas Williams
2015-04-16 18:42:51 -05:00
parent fb177480bd
commit d6a7d14fc5
3 changed files with 36 additions and 7 deletions

View File

@@ -591,6 +591,31 @@ main(int argc, char **argv)
mechoid = string_to_oid(mech_string);
if (mechs_string == NULL) {
/*
* We ought to be able to use the OID set of the one mechanism
* OID given. But there's some breakage that conspires to make
* that fail though it should succeed:
*
* - the NTLM gss_acquire_cred() refuses to work with
* desired_name == GSS_C_NO_NAME
* - the NTLM gss_import_name() also fails, so that merely
* adding --client-name to this program's invocation doesn't
* work around that
* - gss_acquire_cred() with desired_mechs == GSS_C_NO_OID_SET
* does work here because we happen to have Kerberos
* credentials in check-ntlm, and the subsequent
* gss_init_sec_context() call finds no cred element for NTLM
* but plows on anyways, surprisingly enough, and then the
* NTLM gss_init_sec_context() just works.
*
* In summary, there's some breakage in gss_init_sec_context()
* and some breakage in NTLM (and SPNEGO) that conspires against
* us here.
*
* We work around this in check-ntlm and check-spnego by adding
* --mech-types='' to the invocations of this test program that
* require it.
*/
oids[0] = *mechoid;
mechoid_descs.elements = &oids[0];
mechoid_descs.count = 1;