[zeromq-dev] Protection against altering ZMQ internal socketpairs

[Andrew Cholakian]

Agreed completely, it's a terrible situation, and there's only so much that
can be done. However, being able to select/poll is definitely worth it!

By the way eventmachine patched the issue in HEAD, so the ruby eventmachine
binding won't have this issue anymore.

Just thought I'd point this out, there's this hilarity from the strace of me
encountering it, basically, right after the EBADF, it looks like the err
handling code cals dup(2) for some reason and gets to re-use the bad FD!
Luckily, EBADF checking in libzmq would still work, but its kind of funny.

[pid 11284] recvfrom(22, 0x7fffb3881b40, 48, 64, 0, 0) = -1 EBADF (Bad
file descriptor)
[pid 11284] dup(2)                      = 22
[pid 11284] fcntl(22, F_GETFL)          = 0x8001 (flags O_WRONLY|O_LARGEFILE)
[pid 11284] close(22)                   = 0
[pid 11284] write(2, "Bad file descriptor\n", 20Bad file descriptor
) = 20
[pid 11284] write(2, "nbytes != -1 (mailbox.cpp:241)\n", 31nbytes !=
-1 (mailbox.cpp:241)


On Thu, Feb 24, 2011 at 1:38 AM, Martin Sustrik <sustrik at 250bpm.com> wrote:

> Hi Andrew,
>
>
>  My proposal is to check for EBADF somewhere in zmq::mailbox_t::recv and
>> print out a nice message like "Internal socketpair closed, maybe you
>> tried closing a ZMQ FD? Please don't do that"
>>
>
> Yes. Can be done.
>
> The nasty part is that a closed FD can be immediately reused by the OS in
> which case the mailbox would subsequently read/write from a wrong socket :|
>
> Another ugly problem is that the aside of closing the fd, user application
> can read or write to the fd which is undetectable and would mess with 0mq's
> internal logic badly.
>
> In short, it looks like the only real solution to the problem is placing a
> big warning to the documentation saying "NEVER USE THIS FILE DESCRIPTOR FOR
> ANYTHING OTHER THAN POLLING FOR INCOMING DATA".
>
> Thoughts?
> Martin
>



-- 
Andrew Cholakian
http://www.andrewvc.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20110224/30cda356/attachment.htm>