This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author baikie
Recipients baikie, neologix, vstinner
Date 2011-09-18.19:54:10
SpamBayes Score 9.78607e-06
Marked as misclassified No
Message-id <1316375651.72.0.838199389071.issue12981@psf.upfronthosting.co.za>
In-reply-to
Content
I had a look at this patch, and the FD passing looked OK, except
that calculating the buffer size with CMSG_SPACE() may allow more
than one file descriptor to be received, with the extra one going
unnoticed - it should use CMSG_LEN() instead (the existing C
implementation has the same problem, I see).

CMSG_SPACE() exists to allow calculating the space required to
hold multiple control messages, so it essentially gives the
offset for the next cmsghdr struct such that any alignment
requirements are satisfied.

64-bit systems will probably want to ensure that all CMSG_DATA()
payloads are aligned on 8-byte boundaries, and so have
CMSG_SPACE(4) == CMSG_SPACE(8) == CMSG_LEN(8) (the Linux headers,
for instance, align to sizeof(size_t)).  So with a 32-bit int, a
buffer size of CMSG_SPACE(sizeof(int)) would allow *two* file
descriptors to be received.  CMSG_LEN() omits the padding, thus
allowing only one.

I'm not familiar with how the FD-passing facility is used in
multiprocessing, but this seems as if it could be an avenue for
DoS attacks that exhaust the number of file descriptors allowed
for the receiving process.
History
Date User Action Args
2011-09-18 19:54:11baikiesetrecipients: + baikie, vstinner, neologix
2011-09-18 19:54:11baikiesetmessageid: <1316375651.72.0.838199389071.issue12981@psf.upfronthosting.co.za>
2011-09-18 19:54:11baikielinkissue12981 messages
2011-09-18 19:54:10baikiecreate