>>> Same comment about not using the CMSG_ API properly. >> Same comment about it being a broken API; I would say it's broken >> enough that it's not possible to use it properly. > It's horrible, yes. And you're right, CMSG_LEN/CMSG_SPACE was broken > on NetBSD for quite a while. But that was finally fixed about 2 > years ago.
It's the API I think is broken, not any particular implementation of it. >> [...] the property that, upon receiving a message with file >> descriptors in it, all the descriptors would arrive in the recipient >> process's open file descriptors table even if their actual numbers >> were dropped for MSG_CTRUNC reasons; [...] > Since we were pretty horrified by the mess, we actually put some > restrictions on fd passing in OpenBSD: > [...] > 2. When there is not enough room to receive all file descriptors, > recvmsg(2) will simply fail and accept no file descriptors instead > if returning sucessfully and setting MSG_CTRUNC. In what you describe, what happens to the descriptors? Are they closed when recvmsg finds insufficient room, or are they held pending a later recvmsg() with enough cmsg space, or what? It looks to me as though this wedges communication entirely if there are more descriptors in the message than the max the receiver is prepared to accept. I think what NetBSD did was to receive what there's room for, dropping any fds there isn't room for, but truly dropping them, rather than the former behaviour of receiving the fds but dropping their numbers. That is, if the sender sends (say) four descriptors when the receiver provides room for only two ints, the old behaviour would have all four descriptors arrive in the open file table, two of their numbers go into the buffer, and MSG_CTRUNC set. The new behaviour has two descriptors arrive in the open file table and the control data buffer, with the other two descriptors being closed, and MSG_CTRUNC set. > Note that it looks like this was indeed the right decision, as 2) > actually protects OpenBSD from the file descriptor leaks in Keith's > current libxtrans code. So does the current NetBSD way (well, mutatis mutandis). I can think of at least one other reasonable way to address the issue, too, so I'm far from convinced there is a "_the_ right decision" here. > I think the only reasonable thing to do here is disable the file > descriptor passing on systems where file descriptor passing is > (still) broken like that. Perhaps fortunately for X, it's easy to test for if you don't mind building and running a test program - which, since X seems to have now drunk the autoconf koolaid :(, I infer is not a problem. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B _______________________________________________ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel