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