GSS_C_DCE_STYLE vs kg_unseal_stream_iov
Kevin Wasserman
krwasserman at hotmail.com
Mon Oct 10 14:37:22 EDT 2011
In testing my gssalloc changes I observed that there are some
relevant codepaths that are only taken when GSS_C_DCE_STYLE
is used. To test these in the gss-sample apps, I simply locally
added that flag to the static gss_flags in gss-client.c, which
mostly seems to work and in fact exposed some gssalloc memory
bugs in init_ & accept_sec_context which I have fixed. Is adding
that flag for testing purposes a valid thing to try to do? If so,
would it make sense to add it as a commandline option to
gss-client, or is there already another regression test for
GSS_C_DCE_STYLE? After fixing the context setup, the
gss-client/gss-server test worked fine, unless I also have
IOV_SHIM_EXERCISE defined, in which case kg_unseal_stream_iov()
on the server fails due to this logic:
k5unsealiov.c, line 750:
if (toktype != KG_TOK_WRAP_MSG || (ctx->gss_flags & GSS_C_DCE_STYLE)) {
code = EINVAL;
goto cleanup;
}
Is that correct behavior?
Kevin Wasserman
Painless Security, LLC
More information about the krbdev
mailing list