[20133] in Kerberos_V5_Development
Re: GSSAPI security context integrity check
daemon@ATHENA.MIT.EDU (Alexandr Nedvedicky)
Fri Jun 12 02:26:27 2020
Date: Fri, 12 Jun 2020 08:13:59 +0200
From: Alexandr Nedvedicky <alexandr.nedvedicky@oracle.com>
To: Greg Hudson <ghudson@mit.edu>
Message-ID: <20200612061359.GP28942@tbd>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20200507085020.GC29612@tbd>
Cc: krbdev@mit.edu
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: krbdev-bounces@mit.edu
Hello,
just to let you know about the progress of the things...
it looks like issue specific to Solaris at the moment.
</snip>
> > The two filenames had the same suffix (c523660). If I understand
> > correctly, that is the pointer value of the krb5 GSS context object--so
> > both g_seqstate_init() calls were for the same context (which is
> > consistent with the initial sequence numbers being the same). It would
> > be very interesting to know the stack traces of the two
> > g_seqstate_init() calls, although that might be difficult to collect
> > remotely. Normally there should only be one g_seqstate_init() call for
> > a context, from kg_accept_krb5().
>
> I'll ask customer to collect the stack with dtrace. After spending couple
> days browsing through source code the g_seqstate_init() gets only called
> when new security context is born (import, accept or init).
>
> Assuming I interpret the log from SAPware right, we run as GSS acceptor,
> so g_seqstate_init() is being called from kg_accept_krb5() in
> lib/gssapi/krb5/accept_sec_context.c.
>
> yes, that's a good idea to try to collect stack trace using dtrace.
>
we've got a dtrace output, which shows security context export/import
is involved. I suspect there are multiple SAP processes. One of them
accepts security context, exports it and passes to worker process, which
imports it. I've noticed there is a Solaris specific diff, which deals
context serialization. Therefore I think the issue might be specific to
Solaris. I'll send pull request in case the investigation will reveal
it's bug in MIT kerberos.
thanks and
regard
sashan
_______________________________________________
krbdev mailing list krbdev@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev
