On Feb 14, 2007, at 18:53, Public Submitter via RT wrote:
>> From code inspection sendto_kdc() is fundamentally flawed insofar as
> it assumes that when select(2) returns, it has consumed all of the
> time that it was allotted.  This is incorrect in two cases:

We should be going back into the select call unless  
krb5int_cm_call_select returns zero *and* sets *sret to 0.

>    1.  if the process catches signals then select(2) will return
>        EINTR, and

It looks like that won't be handled properly, true... probably the  
call_select routine should check for that, and just try calling  
select again.

>    2.  while processing a TCP connexion, select(2) can return true
>        but the subsequent read will not contain enough data to
>        complete the request.

> In both cases, it appears from code inspection that sendto_kdc() will
> proceed to either send a new UDP packet or start a new TCP connexion
> assuming that the specified delay was entirely consumed.

The while loop in service_fds should continue until:

1) all open file descriptors have been closed (selstate->nfds)
2) krb5int_cm_call_select returns nonzero, which indicates an error  
return from gettimeofday or select (including, yes, EINTR)
3) krb5int_cm_call_select returns zero but sets *sret (number of  
ready fds) to 0, which should happen only when the specified end time  
is reached
4) the fd service routine returns nonzero, which for the TCP sockets  
should only be if the full message is received

If an incomplete message is received, and there's still time left, we  
should wind up back in the select call.

>   In a worst
> case scenario, e.g. a process that spawns and catches lots of kids,
> the loop might exit prematurely with an error.
>
> Actually, it looks like if select(2) returns EINTR then the entire
> loop punts returning an error.  In short, this means that processes
> cannot both process signals and reliably use Kerberos...

Yeah, that's a bug...

Ken