From: Mike Pomraning <redmine@...>
Date: 2009-10-22T12:43:37+09:00
Subject: [ruby-core:26222] [Bug #2250] IO::for_fd() objects' finalization dangerously closes underlying fds

Bug #2250: IO::for_fd() objects' finalization dangerously closes underlying fds
http://redmine.ruby-lang.org/issues/show/2250

Author: Mike Pomraning
Status: Open, Priority: High
Category: core
ruby -v: ruby 1.9.1p243 (2009-07-16 revision 24175) [i686-linux]

1. Expected behavior:

An IO object created by IO::for_fd(a_socket_fd) should *not* call close(2) on its underlying fd upon finalization.  The object did not allocate the fd, and so cannot safely nor politely close it.

2. Observed behavior:

Instead, an IO object created by IO::for_fd(a_socket_fd) will attempt to close(2) its underlying socket fd upon finalization.

3. How to reproduce:

The attached script and trivial extension module demonstrate that an IO::for_fd()-created object may secretly close(2) the fd behind an innocent File.new(...) object, causing operations on that File object to fail for no reason apparent in (nor knowable to) the ruby code.  On 32-bit Linux under ruby-1.9 (or 1.8. for that matter), it produces:

  $ ruby io-finalize.rb
  #<File::Stat dev=0x11, ino=1193, ....
  Finalizing an IO::for_fd() object...
  io-finalize.rb:29:in `stat': Bad file descriptor - /dev/null (Errno::EBADF)
          from io-finalize.rb:29


4. Why this is very bad:

In practice, fds passed to for_fd() may be exposed by extension modules, which modules are responsible for the cleanup of the file descriptor.  Thus, close(2)ing upon finalization may rudely and dangerously close a file descriptor already closed and reassigned to some unrelated bit of code, causing baffling, "action at a distance" failures.

Indeed, the script to reproduce this failure simulates the experience of two different users of two different ruby bindings to PostgreSQL's libpq (ruby-pg and dbd-altpg), whose uses of Kernel.select( [ IO.for_fd(pg_underlying_socket) ] ... ) thus caused failures elsewhere.

Casual testing suggests that this behavior also applies to at least one other non-regular file type, the FIFO.


----------------------------------------
http://redmine.ruby-lang.org