GSSAPI security context integrity check

Alexandr Nedvedicky alexandr.nedvedicky at
Fri Jun 12 02:13:59 EDT 2020


just to let you know about the progress of the things...
it looks like issue specific to Solaris at the moment.

> > 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

More information about the krbdev mailing list