From: akr@...
Date: 2019-01-10T07:10:29+00:00
Subject: [ruby-core:90972] [Ruby trunk Feature#2250][Rejected] IO::for_fd() objects' finalization dangerously closes underlying fds

Issue #2250 has been updated by akr (Akira Tanaka).

Status changed from Open to Rejected

We discussed this issue today's Ruby developer meeting.

Our conclusion is that changing the default behavior of IO.for_fd is
too incompatible.  It changes good working program to FD-leaking program.
It is another big issue, especially problematic for long-running server
and very very difficult to debug. 


----------------------------------------
Feature #2250: IO::for_fd() objects' finalization dangerously closes underlying fds
https://bugs.ruby-lang.org/issues/2250#change-76183

* Author: pilcrow (Mike Pomraning)
* Status: Rejected
* Priority: Normal
* Assignee: Eregon (Benoit Daloze)
* Target version: 
----------------------------------------
=begin
 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.
=end


---Files--------------------------------
syssocket.c (605 Bytes)
io-finalize.rb (853 Bytes)


-- 
https://bugs.ruby-lang.org/

Unsubscribe: <mailto:ruby-core-request@ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>