[ruby-core:29065] Re: [Feature #1291] O_CLOEXEC flag missing for Kernel::open

2010/3/27 Motohiro KOSAKI <[e-mail]>:

> 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

My intent behind [ruby-core:22899] is to fix the race shown here.

O_CLOEXEC and friends (F_DUPFD_CLOEXEC, etc.) are good tool to avoid the
race condition.
They is defined in POSIX now.

However they are not popular.
I don't know platforms with O_CLOEXEC other than Linux.
But the race condition exists not only on Linux.
I want to fix the race on all platforms.

Defining File::CLOEXEC as O_CLOEXEC is not enough to fix the race.
Applications should be modified to use it.
Since O_CLOEXEC is not portable, it should be used conditionally as:

  f = open(filename, File::WRONLY|(defined?(File::CLOEXEC)?File::CLOEXEC:0))
  f.close_on_exec = true

It is too complicated to believe usual programmers do it for all open call.

So, my idea is modifying Ruby (incompatibly) to set CLOEXEC flag by
* using O_CLOEXEC for all open() on Linux, and
* using FD_CLOEXEC immediately after open() on non-Linux.

Actually this minimize the race instead of fix on non-Linux.
But I don't have practical idea better than this.

Since O_CLOEXEC is standardized by POSIX, I guess this idea can fix
the race in many platforms in future.

I think POSIX cannot change open() to set CLOEXEC by default because
compatibility.

But I think Ruby can accept this incompatibility.

Apart from my idea, defining File::CLOEXEC as 0 on non-Linux simplify the code:

  f = open(filename, File::WRONLY|File::CLOEXEC)
  f.close_on_exec = true

Defining File::CLOEXEC as some number to emulate O_CLOEXEC simplify more:

  f = open(filename, File::WRONLY|File::CLOEXEC)

So I don't against O_CLOEXEC emulation.
It makes easier to minimize the race.

I still don't believe usual programmers uses it, though.
-- 
Tanaka Akira