Re: Possible message multiplexing problem

[Michael B Allen <miallen@ioplex.com>]

On Mon, 23 Jun 2008 08:49:43 -0700
"Henry B. Hotz" <hotz@jpl.nasa.gov> wrote:

> 
> On Jun 22, 2008, at 3:06 PM, Michael B Allen wrote:
> 
> > Hi,
> >
> > How does Heimdal match up responses with requests?
> >
> > Doesn't there have to be some kind of multiplex ID?
> >
> > I added a DNS cache and now my multi-process tourture-test is giving  
> > me
> > a very occasional errors from gss_acquire_cred:
> >
> > GSS_S_FAILURE: Additional pre-authentication required
> >
> > Looking at a capture around the point of failure I see the following:
> >
> > ...
> > TGS-REQ
> > TGS-REP
> > AS-REQ (nonce: 2261734593)
> > AS-REQ (nonce: 2261734593)
> > KRB-ERROR: KRB5KDC_ERR_PREAUTH_REQUIRED
> > AS-REQ (nonce: 2261734593 + preauth)
> > KRB-ERROR: KRB5KDC_ERR_PREAUTH_REQUIRED
> > AS-REP
> > AS-REQ (nonce: 2260112736)
> > KRB-ERROR: KRB5KDC_ERR_PREAUTH_REQUIRED
> > ...
> >
> > Note there are multiple processes issuing requests from the same  
> > source
> > port [1].
> >
> > Natrually MS returns KRB5KDC_ERR_PREAUTH_REQUIRED initially because
> > no preauth was supplied. That is normal. But it seems without the DNS
> > lookups things happen fast enough that two AS-REQs make it out within
> > 1/10th of a millisecond and AFAICT they are identical including the  
> > nonce.
> >
> > So I have to wonder if the client is interpreting the second
> > KRB5KDC_ERR_PREAUTH_REQUIRED as the response to the retried AS-REQ of
> > the first process when in reality it was actually the response to the
> > AS-REQ of the second process.
> >
> > Can anyone concur or refute what is happening here?
> >
> > Mike
> >
> > [1] I suppose if the Kerberos library was not initialized until after
> > workers were forked the source port would be different.
> 
> I'm not clear that it's possible to do the matchup like I think you  
> want.  I thought the multi-thread model was that every thread that  
> wanted to do Kerberos needed its own context.

I do. I only create krb5_contexts transiently. And I'm using a
multi-process model.

I trigger some libkrb5 actions in my Apache module initialization routine
and then Apache fork()s workers. Perhaps the workers are inheriting the
socket?

Does Heimdal close the socket krb5_free_context? It's unfortunate that
99.999% of the time it does not need to. It's only the fork-inherit case
that is an issue. Could the socket code make a note the pid_t when the
socket was opened and then disconnect / reconnect the it if pid_t !=
getpid()?

FYI: I am using a modified 0.7.2. I do not have a test-harness for a
current Heimdal version.

Mike

-- 
Michael B Allen
PHP Active Directory SPNEGO SSO
http://www.ioplex.com/