Assertion failed at tkey.c:490 due to missing GSSAPI

Andrew Bartlett abartlet at samba.org
Thu Mar 8 02:26:13 UTC 2012


I'm working with fellow Samba developer Kelly (CC'ed), who has been
getting:

tkey.c:490: ENSURE(result == (((1) << 16) + 28) || result == 0) failed,
back trace

Looking at the Bind 9.8.1 sources, it seems this is the code
responsible:

	/*
	 * Note that tctx->gsscred may be NULL if tctx->gssapi_keytab is set
	 */
	result = dst_gssapi_acceptctx(tctx->gsscred, tctx->gssapi_keytab,
				      &intoken,
				      &outtoken, &gss_ctx,
				      dns_fixedname_name(&principal),
				      tctx->mctx);
	if (result == DNS_R_INVALIDTKEY) {
		if (tsigkey != NULL)
			dns_tsigkey_detach(&tsigkey);
		tkeyout->error = dns_tsigerror_badkey;
		tkey_log("process_gsstkey(): dns_tsigerror_badkey");    /* XXXSRA */
		return (ISC_R_SUCCESS);
	} else if (result == ISC_R_FAILURE)
		goto failure;
	ENSURE(result == DNS_R_CONTINUE || result == ISC_R_SUCCESS);

The ENSURE() statement does not consider that dst_gssapi_acceptctx()
could return (ISC_R_NOMEMORY) or (ISC_R_NOTIMPLEMENTED) if not compiled
with the 'ideal' headers.

We are working to fix up Kelly's workstation to have GSSAPI, but
otherwise this appears to be an unauthenticated DoS on the server, so we
figured you might be interested. 

Thanks, 

Andrew Bartlett

-- 
Andrew Bartlett                                http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org



More information about the bind-workers mailing list