Feature #1291 [ruby-core:22893]

O_CLOEXEC flag missing for Kernel::open

Added by David Martin 501 days ago. Updated 118 days ago.

Status :Assigned Start :03/15/2009
Priority :Normal Due date :
Assigned to :Yukihiro Matsumoto % Done :

0%

Category :core
Target version :1.9.x

Description

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().

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

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

History

03/15/2009 12:55 PM - Nobuyoshi Nakada

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

09/18/2009 04:40 AM - Marc-Andre Lafortune

  • Category set to core
  • Assigned to set to Yukihiro Matsumoto

03/26/2010 11:42 PM - Motohiro KOSAKI

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.

03/26/2010 11:46 PM - Motohiro KOSAKI

Grr, I forgot to fix commnet. fixed.

03/27/2010 12:41 AM - Nikolai Weibull

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

03/27/2010 09:59 AM - Nobuyoshi Nakada

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

03/27/2010 04:08 PM - Motohiro KOSAKI

> 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

04/02/2010 08:18 AM - Kazuhiro NISHIYAMA

  • Status changed from Open to Assigned
  • Target version set to 1.9.x

Also available in: Atom PDF