Re: openssh and sendmsg() problem

[Szabolcs Nagy <nsz@port70.net>]

* orc <orc@sibserver.ru> [2012-06-27 03:39:34 +0800]:
> On Tue, 26 Jun 2012 15:08:23 -0400
> Rich Felker <dalias@aerifal.cx> wrote:
> > On Wed, Jun 27, 2012 at 02:16:40AM +0800, orc wrote:
> > > > > On Tue, 26 Jun 2012 12:01:06 -0400
> > > > > Rich Felker <dalias@aerifal.cx> wrote:
> > > > > > > * orc <orc@sibserver.ru> [2012-06-26 19:01:46 +0800]:
> > > > > > > > strace shows that sendmsg system call returns EINVAL:
> > > > > > > > 
> > > > > > > > sendmsg(5, {msg_name(0)=NULL, msg_iov(1)=[{"\0", 1}],
> > > > > > > > msg_controllen=24, {cmsg_len=20, cmsg_level=SOL_SOCKET,
> > > > > > > > cmsg_ type=SCM_RIGHTS, {4, 385875968}}, msg_flags=0}, 0)
> > > > > > > > = -1 EINVAL (Invalid argument)
> > > > > > > > 
> > > 
> > > strace from glibc system on this syscall:
> > > 
> > > sendmsg(5, {msg_name(0)=NULL, msg_iov(1)=[{"\0", 1}],
> > > msg_controllen=24, {cmsg_len=20, cmsg_level=SOL_SOCKET,
> > > cmsg_type=SCM_RIGHTS, {4}}, msg_flags=0}, 0) = 1 sendmsg(5,
> > > {msg_name(0)=NULL, msg_iov(1)=[{"\0", 1}], msg_controllen=24,
> > > {cmsg_len=20, cmsg_level=SOL_SOCKET, cmsg_type=SCM_RIGHTS, {6}},
> > > msg_flags=0}, 0) = 1
> > 
> > I don't quite understand this from the strace, but it looks like
> > there's an issue with the size of cmsg structures on 64-bit machines
> > due to another buggy kernel socklen_t/size_t mismatch. I'm not sure
> > how it can be worked around, but musl's failure to work around it is a
> > flaw that needs to be fixed. glibc just violates POSIX and defines
> > the wrong type.
> > 
> > Rich
> 
> And kernel too.
> 
> Both they define incompatible msghdr and cmsghdr structs.
> The problem sits in cmsghdr struct, changing it's first member type to
> 'size_t' solves openssh issue.

so the issue is that the kernel and glibc uses size_t for socklen_t
in struct msghdr and struct cmsghdr as well

musl fixes msghdr but not cmsghdr
(by using int + padding)

where is it specified in posix that socklen_t should be unsigned int?
it seems using size_t would make things easier..

i only see a recommendation that
"To forestall portability problems, it is recommended that applications
not use values larger than 2^31 -1 for the socklen_t type."