Feature #1291 [ruby-core:22893]
O_CLOEXEC flag missing for Kernel::open
| 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().
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
- 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.
03/26/2010 11:46 PM - Motohiro KOSAKI
- File 0001-O_CLOEXEC.patch added
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