Feature #1291

O_CLOEXEC flag missing for Kernel::open

Added by David Martin about 5 years ago. Updated over 2 years ago.

[ruby-core:22893]
Status:Closed
Priority:Normal
Assignee:Motohiro KOSAKI
Category:core
Target version:2.0.0

Description

=begin
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().
=end

0001-O_CLOEXEC.patch Magnifier (705 Bytes) Motohiro KOSAKI, 03/26/2010 11:42 PM

0001-O_CLOEXEC.patch Magnifier (712 Bytes) Motohiro KOSAKI, 03/26/2010 11:46 PM


Related issues

Related to ruby-trunk - Feature #4512: [PATCH] ext/fcntl/fcntl.c: add F_DUPFD_CLOEXEC constant Closed 03/20/2011
Duplicates ruby-trunk - Feature #5041: Set FD_CLOEXEC for all fds (except 0, 1, 2) Closed 10/24/2011

Associated revisions

Revision 31430
Added by Motohiro KOSAKI almost 3 years ago

  • io.c (Init_IO): Added File::CLOEXEC constant. [Feature #1291]
  • test/ruby/testio.rb (TestIO#testo_cloexec): test for File::CLOEXEC.

History

#1 Updated by Nobuyoshi Nakada about 5 years ago

=begin
Hi,

At Sun, 15 Mar 2009 09:14:24 +0900,
David Martin wrote in :

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

=end

#2 Updated by Marc-Andre Lafortune over 4 years ago

  • Category set to core
  • Assignee set to Yukihiro Matsumoto

=begin

=end

#3 Updated by Motohiro KOSAKI about 4 years ago

=begin
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", ORDONLY) = 3
open("foo", O
RDWR|OCREAT|OCLOEXEC, 0644) = 3

btw, glibc fopen(3) has "e" mode extention. It mean fopen("foo", "r+e") is equivalent
open("foo", ORDWR|OCLOEXEC). 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.

=end

#4 Updated by Motohiro KOSAKI about 4 years ago

=begin
Grr, I forgot to fix commnet. fixed.
=end

#5 Updated by Nikolai Weibull about 4 years ago

=begin
On Fri, Mar 26, 2010 at 16:02, stygian23 stygian23@aol.com 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

=end

#6 Updated by Nobuyoshi Nakada about 4 years ago

=begin
Hi,

At Fri, 26 Mar 2010 23:46:22 +0900,
Motohiro KOSAKI wrote in :

File 0001-O_CLOEXEC.patch added

I'm not against it, although I hope it should be automatic in
the future as mentioned in .

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

--
Nobu Nakada

=end

#7 Updated by Motohiro KOSAKI about 4 years ago

=begin

I'm not against it, although I hope it should be automatic in
the future as mentioned in .

Umm, sorry, I haven't catch your mention. I think IO::closeonexec
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(OCLOEXEC) and fcntl(FDCLOEXEC) are differenct
security meaning. To provide OCLOEXEC 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 =end

#8 Updated by Kazuhiro NISHIYAMA about 4 years ago

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

=begin

=end

#9 Updated by Motohiro KOSAKI almost 3 years ago

  • Status changed from Assigned to Closed

#10 Updated by Motohiro KOSAKI almost 3 years ago

  • 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.

#11 Updated by Motohiro KOSAKI almost 3 years ago

  • Assignee changed from Yukihiro Matsumoto to Motohiro KOSAKI

#12 Updated by Motohiro KOSAKI over 2 years ago

  • 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. [Feature #1291]
  • test/ruby/testio.rb (TestIO#testo_cloexec): test for File::CLOEXEC.

Also available in: Atom PDF