Re: Kernel or userland bug: file descript passing in Postfix

[mlelstv%serpens.de@localhost (Michael van Elst)]

tron%zhadum.org.uk@localhost (Matthias Scheler) writes:

>After a lot of debugging and by comparing with a demo program kindly
>provided by Michael van Elst I came up with the attached patch for
>Postfix which seems to fix the problem.

>Is this really a bug in Postfix (in which I case I will commit the patch)
>or is it a kernel bug?

Whatever is considered a bug.... Postfix was changed this way
for compatibility with LP64.

RFC3542 which describes the interface (for IPv6) says that we
do it right:

   [...] While sending an
   application may or may not include padding at the end of last
   ancillary data in msg_controllen and implementations must accept both
   as valid.  On receiving a portable application must provide space for
   padding at the end of the last ancillary data as implementations may
   copy out the padding at the end of the control message buffer and
   include it in the received msg_controllen.  When recvmsg() is called
   if msg_controllen is too small for all the ancillary data items
   including any trailing padding after the last item an implementation
   may set MSG_CTRUNC.

msg_controllen is the size of the buffer for one or more control messages.

CMSG_LEN is the unpadded size of a control message.
CMSG_SPACE is the padded size of a control message.

The RFC allows us to

"copy out the padding at the end of the control message buffer",

an insists that portable applications must provide such a buffer.
I.e. postfix doesn't adhere to the RFC because it only provides
a smaller buffer.

On the other hand, there is nothing that forbids us to be tolerant
and support receiving into a buffer without space for padding.

-- 
-- 
                                Michael van Elst
Internet: mlelstv%serpens.de@localhost
                                "A potential Snark may lurk in every tree."