Mantis Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0005568OCamlOCaml otherlibspublic2012-03-30 23:442013-08-05 12:22
Reportergoswin 
Assigned To 
PrioritynormalSeverityminorReproducibilityalways
StatusresolvedResolutionfixed 
PlatformOSLinuxOS Version
Product Version3.12.1 
Target Version4.01.0+devFixed in Version4.01.0+dev 
Summary0005568: Unix.open_flag lacks O_CLOEXEC
Description       O_CLOEXEC (Since Linux 2.6.23)
              Enable the close-on-exec flag for the new file descriptor.
              Specifying this flag permits a program to avoid additional
              fcntl(2) F_SETFD operations to set the FD_CLOEXEC flag. Addi-
              tionally, use of this flag is essential in some multithreaded
              programs since using a separate fcntl(2) F_SETFD operation to
              set the FD_CLOEXEC flag does not suffice to avoid race condi-
              tions where one thread opens a file descriptor at the same time
              as another thread does a fork(2) plus execve(2).

There also some other flags missing but O_CLOEXEC has serious security implications.
TagsNo tags attached.
Attached Files

- Relationships
related to 0005256feedback Processes opened using Unix.open_process* inherit all opened file descriptors (including sockets) 
child of 0005569resolved missing Unix.dup_cloexec, Unix.get_cloexec and Unix.set_cloexec 

-  Notes
(0007256)
doligez (administrator)
2012-04-01 00:30

See note in PR#5569.
(0007260)
gerd (reporter)
2012-04-02 10:47

I support this because it avoids a race condition between opening a file and executing a command in a multi-threaded app. If you don't open with O_CLOEXEC, it can happen that the exec() is done between open() and the fcntl() setting the flag, and the file remains open in the child process. See also PR#5256.

O_CLOEXEC is covered by POSIX.

Of course, this is only a partial solution to the mentioned problem, but this not our issue, but POSIX': The other syscalls creating file descriptors don't have an O_CLOEXEC flag.
(0007270)
goswin (reporter)
2012-04-03 15:28

I would rather consider this a parent of 0005569, not a child.

Be advised that this wouldn't be just usefull for Unix.open_file. Other modules (extunix, lwt, ...) are using Unix.open_flags for syscalls that do accept O_CLOEXEC and would benefit from supporting a race-free CLOEXEC, too.
(0010062)
xleroy (administrator)
2013-08-01 14:16

Add O_CLOEXEC flag to Unix.openfile, with emulation if not supported by the OS. Commits r13961 on version/4.01 and r13962 on trunk. Win32 implementation needs testing.
(0010087)
avsm (reporter)
2013-08-03 23:05

Upstream patches to Lwt/Core have now been applied to OPAM, to fix the builds with the new flag.
https://github.com/OCamlPro/opam-repository/pull/936 [^]
(0010113)
goswin (reporter)
2013-08-05 12:22

I'm not sure if emulation is the right thing to do if the OS does not support the flag. You can't emulate it atomically and then you have the race condition back. It might be saver to fail if O_CLOEXEC is not supported.

- Issue History
Date Modified Username Field Change
2012-03-30 23:44 goswin New Issue
2012-04-01 00:28 doligez Relationship added child of 0005569
2012-04-01 00:30 doligez Note Added: 0007256
2012-04-01 00:30 doligez Status new => feedback
2012-04-02 10:47 gerd Note Added: 0007260
2012-04-03 15:18 xleroy Relationship added related to 0005256
2012-04-03 15:28 goswin Note Added: 0007270
2012-04-03 15:28 goswin Status feedback => new
2012-04-10 17:40 doligez Status new => acknowledged
2012-07-09 17:42 doligez Target Version => 4.01.0+dev
2012-07-31 13:36 doligez Target Version 4.01.0+dev => 4.00.1+dev
2012-08-06 18:33 xleroy Target Version 4.00.1+dev => 4.01.0+dev
2013-08-01 14:16 xleroy Note Added: 0010062
2013-08-01 14:16 xleroy Status acknowledged => resolved
2013-08-01 14:16 xleroy Resolution open => fixed
2013-08-01 14:16 xleroy Fixed in Version => 4.01.0+dev
2013-08-03 23:05 avsm Note Added: 0010087
2013-08-05 12:22 goswin Note Added: 0010113


Copyright © 2000 - 2011 MantisBT Group
Powered by Mantis Bugtracker