[krbdev.mit.edu #5540] recvmsg, msg_name, and RPC

[Ken Raeburn via RT]

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  
port.

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 0.0.0.0.  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.)

Ken