[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Possible message multiplexing problem

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:
>>> ...
>>> AS-REQ (nonce: 2261734593)
>>> AS-REQ (nonce: 2261734593)
>>> AS-REQ (nonce: 2261734593 + preauth)
>>> AS-REP
>>> AS-REQ (nonce: 2260112736)
>>> ...
>>> 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/