Potential bug using TCP for kinit to KDC communication

[Oli Mlist]

Greg,

Thanks, you are right, in the case of service_tcp_fd(), the state is
re-analyzed after a poll() and set up as new with cm_get_ssflags(). I
double checked my setup and found out a port configuration issue with my
KDC. I fixed it and TCP is working fine now.

-- Oli.


On Mon, Apr 2, 2012 at 6:23 PM, Greg Hudson <ghudson at mit.edu> wrote:

> On 04/02/2012 11:30 AM, Oli Mlist wrote:
> > - at the end of start_connection(), there is an ssflags local variable
> into
> > which the SSF_READ flag is being set (among others), and this state is
> > saved through cm_add_fd().
> > - for TCP sockets, the service_tcp_fd() function is called, running a
> state
> > machine.
> > - inside service_tcp_fd(), for the CONNECTING  state, a check is made for
> > the SSF_READ flag. If this flag is set, a comment tells the KDC is
> sending
> > data to us, which is interpreted as an error, so the TCP socket is
> > disconnected by the client. As seen above, this SSF_READ flag had been
> > explicitly set at the end of start_connection().
>
> The flags to service_tcp_fd() come from cm_get_ssflags(), which
> processes the revents member of the pollfd, not the events member which
> was set in cm_add_fd().  So, poll() is saying that a read on the TCP
> socket wouldn't block, implying that there is either data to be read or
> a socket error to be processed, neither of which happens during a
> successful exchange.
>
> > Thanks to let me know if this is indeed a but or whether I am missing
> > something,
>
> I put together a simple test case and was able to communicate with a KDC
> over TCP.
>