[krbdev.mit.edu #2277] socket leak in sendto_kdc.c, start_connection()

[Bill Dodd]

>>>>> "Ken" == Ken Raeburn via <RT" <rt-comment at krbdev.mit.edu>> writes:

Ken> [resend; my original message didn't get sent to the submitter]
Ken> Begin forwarded message:

>> From: Ken Raeburn <raeburn at mit.edu>
>> Date: Tue Feb 24, 2004  21:27:48 US/Eastern
>> To: rt-comment at krbdev.mit.edu
>> Subject: Re: [krbdev.mit.edu #2277] socket leak in sendto_kdc.c, 
>> start_connection()
>> 
>> On Tuesday, Feb 24, 2004, at 18:56 US/Eastern, Bill Dodd via RT wrote:
>> 
>>> In start_connection(), if the connect() fails (e.g. with 
>>> ECONNREFUSED),
>>> an error is returned, but the socket is not closed.
>> 
>> Under what circumstances (aside from, maybe, running the client and 
>> KDC on the same host) can you get back ECONNREFUSED from a connect 
>> call on a non-blocking socket?

Ken,

Yes, the client and KDC were on the same host when I saw the
ECONNREFUSED. Sorry, I should have said that in my original note. I
was thinking there could be other conditions/errors where you could go
down that error path, but as you say, that might be a pretty rare
condition.


>> Seems to me that to get and process 
>> the ICMP message from another host, the process would have to, well, 
>> block.  I suppose, if the scheduler switched to another process during 
>> the connect call, it's possible a response from another nearby host 
>> could come in before the process continued, but it seems like a tricky 
>> race condition more than a reliable leak.
>> 
>> It's definitely a bug, I'm just trying to get a sense of how serious...
>> 
>>> To observe the leak, set udp_preference_limit to 1 in krb5.conf and
>>> run kdc5_hammer with a large repeat count against a kdc that only
>>> listens on UDP. Observe the open files/sockets with lsof. A contrived
>>> scenario to be sure, but it can be seen in more legitimate cases as
>>> well.
>> 
>> Were you testing this with a KDC on the same host, or another host?
>> 
>> Ken
>> 

I just re-ran the same scenario with the client on a different machine
than the KDC and hit a different, more severe problem. The client is
dying with a "broken pipe" error in writev() in service_tcp_fd().
This is on AIX. I'll have to debug this some more.

Thanks for following up,
-bill