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