[17278] in Kerberos_V5_Development
GSS_C_DCE_STYLE vs kg_unseal_stream_iov
daemon@ATHENA.MIT.EDU (Kevin Wasserman)
Mon Oct 10 14:37:29 2011
Message-ID: <SNT101-DS2397D97F141965A7CD497EB5FD0@phx.gbl>
From: "Kevin Wasserman" <krwasserman@hotmail.com>
To: <krbdev@mit.edu>
In-Reply-To: <1317921933-22035-1-git-send-email-hartmans@painless-security.com>
Date: Mon, 10 Oct 2011 14:37:22 -0400
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: krbdev-bounces@mit.edu
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
_______________________________________________
krbdev mailing list krbdev@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev
