GSSAPI security context integrity check

[Alexandr Nedvedicky]

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