Feature #1291: O_CLOEXEC flag missing for Kernel::open

Hi,

At Sun, 15 Mar 2009 09:14:24 +0900,
David Martin wrote in [ruby-core:22893]:
> Linux has a the most useful O_CLOEXEC flag for open() that
> sets the CLOEXEC flag on the new file descriptor.
> 
> You can currently set the CLOEXEC flag on an open file
> descriptor using IO::fcntl(), but note that this does *not*
> work in a multithreaded program: If one thread does
> open/fcntl while another does an exec, there is a race
> condition that could produce a file descriptor leak.  The
> only safe way to open a file with the CLOEXEC flag set in
> general (as far as I know) is to use the O_CLOEXEC flag to
> open().

Is it Linux only?

-- 
Nobu Nakada

• Category set to core
• Assignee set to matz (Yukihiro Matsumoto)

• File 0001-O_CLOEXEC.patch added

Sure. This is linux specific feature. and I attached the proposal patch.

test way:

test.rb
--------------------------
open("foo", File::CREAT|File::RDWR|File::CLOEXEC, 0644)

strace -e open ruby test.rb
-------------------------------
(snip)
open("./test.rb", O_RDONLY)             = 3
open("foo", O_RDWR|O_CREAT|O_CLOEXEC, 0644) = 3


btw, glibc fopen(3) has "e" mode extention. It mean fopen("foo", "r+e") is equivalent
open("foo", O_RDWR|O_CLOEXEC). but I don't change mode spec of File::open, because
I don't think this is enough widly used nor enough widly known from people.

thanks.

• File 0001-O_CLOEXEC.patch added

Grr, I forgot to fix commnet. fixed.

On Fri, Mar 26, 2010 at 16:02, stygian23 <[e-mail]> wrote:
> How do I unsubscribe to this, as its currently flooding my work e-mail and I
> don't have the time to follow my intellectual curiosity.

Nor time to Google [1] for an answer, it seems.

[1] http://www.google.se/search?q=ruby-core+unsubscribe

Hi,

At Fri, 26 Mar 2010 23:46:22 +0900,
Motohiro KOSAKI wrote in [ruby-core:29039]:
> File 0001-O_CLOEXEC.patch added

I'm not against it, although I hope it should be automatic in
the future as mentioned in [ruby-core:22899].

Also, IMHO, all those constants should be defined on all
platforms for portability, like as File::BINARY.

-- 
Nobu Nakada

> I'm not against it, although I hope it should be automatic in
> the future as mentioned in [ruby-core:22899].

Umm, sorry, I haven't catch your mention. I think IO::close_on_exec
can only be used for already opened file. I think they have different 
semantics.

If you mean introducing new special variable, I'm not againt it.

> Also, IMHO, all those constants should be defined on all
> platforms for portability, like as File::BINARY.

No. I dislike it. open(O_CLOEXEC) and fcntl(FD_CLOEXEC) are differenct
security meaning. To provide O_CLOEXEC emulation logic mean to make 
security issue. Please remember why O_CLOEXEC was introduced although 
fcntl(FD_CLOEXEC) was already existed.

 -> see http://udrepper.livejournal.com/20407.html

note: "set close-on-exec by default" and "to emulate O_CLOEXEC" are
perfectly different topic. I only againt latter.

- kosaki

• Status changed from Open to Assigned
• Target version set to 2.0.0

• Status changed from Assigned to Closed

r31430

• Status changed from Closed to Assigned

I've reverted r31430 today. because boron chkbuild test result says, An old linux kernel ignore O_CLOEXEC silently instead of return an error. It may lead to bring new security risk. So, we have to be pending it until finish to implement proper fallback logic.

• Assignee changed from matz (Yukihiro Matsumoto) to kosaki (Motohiro KOSAKI)

• Status changed from Assigned to Closed
• % Done changed from 0 to 100

This issue was solved with changeset r31430. David, thank you for reporting this issue. Your contribution to Ruby is greatly appreciated. May Ruby be with you. ---------- * io.c (Init_IO): Added File::CLOEXEC constant. [ruby-core:22893] [Feature #1291] * test/ruby/test_io.rb (TestIO#test_o_cloexec): test for File::CLOEXEC.