Skip Menu |

From: Ken Raeburn <raeburn@MIT.EDU>
Subject: recvmsg, msg_name, and RPC
Date: Fri, 20 Apr 2007 22:04:21 -0400
To: krb5-bugs@MIT.EDU
Download (untitled) / with headers
text/plain 1.5KiB
Tom and I have been digging into this a little bit. It appears that
some man pages (including Solaris 10) claim that for recvmsg, the
msg_name field indicates where the *receiving* address should be
recorded, rather than the sender's address as in current
documentation. POSIX specs, glibc man pages, Linux 2.6.9 behavior,
and Solaris 10 behavior all indicate that it is in fact the sender's
address that's returned. And a peek at the 4.3BSD recvfrom source
code suggests that perhaps never was implemented that way.

So, the new code in the KDC seems to be okay.

However, the RPC code we've got calls recvmsg with MSG_PEEK, thinking
that it can get the local address, and then calls recvmsg to get the
remote address and the data. I instrumented the RPC code in
question, and on both Solaris and Linux I found that the so-called
local address and the remote address indicated the same address and

Which means (1) the RPC code is buggy, and (2) probably nothing
currently using it cares.

For a tiny bit of performance, we could kill the recvmsg call and
always store Or use IP_PKTINFO where it's available, but we
still wind up with platforms where we can't tell, unless we switch to
using a socket per local address like the KDC code does (when IP{,V6}
_PKTINFO aren't available).

Possibly we might be able to adapt the KDC code to implement the
socket listening part of the RPC code, if we separate out the KDC-
specific bits. (Even if we don't care about random RPC code, it
might be worth doing for kadmind, krb524d, etc.)

Subject: Re: [ #5540] recvmsg, msg_name, and RPC
From: Tom Yu <tlyu@MIT.EDU>
Date: Sun, 22 Apr 2007 19:32:26 -0400
The code in lib/rpc/svc_udp.c which erroneously tries to use MSG_PEEK
to extract the local address appears to have been added as part of the
AUTH_GSSAPI work. The error was probably the result of someone
believing the incorrect statements about struct msghdr in various
man pages.