Re: Possible message multiplexing problem

["Henry B. Hotz" <hotz@jpl.nasa.gov>]

On Jun 23, 2008, at 9:42 AM, Michael B Allen wrote:

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

I think you know more than I do, but it sounds plausible.

Along the lines of what I first said:  I'm not clear that it's  
possible to match up requests/responses when they share the same  
client source port.  I don't know how the OS could determine which  
thread/process to deliver a response to, and I don't think there is  
anything in the Kerberos protocol messages intended to help with that.

I suppose that's just restating the problem and may not be helpful.

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