open() doesn't set O_CLOEXEC flag

Question

I try to set O_CLOEXEC flag using open() and have no sucess.

Consider the following microtest:

#include <stdio.h>
#include <fcntl.h>

int main() {
  int fd = open("test.c", O_RDONLY | O_CLOEXEC);
  int ret = fcntl(fd, F_GETFL);
  if(ret & O_CLOEXEC) {
    printf("OK!\n");
  } else {
    printf("FAIL!\n");
  }
  printf("fd = %d\n", fd);
  printf("ret = %x, O_CLOEXEC = %x\n", ret, O_CLOEXEC);
  return 0;
}

When running on linux with kernel version 2.6 the test succeeds and prints "OK!", but fails with 3.8 or 3.9 kernels.

What's wrong? Thanks!

notice that the flag can be true even before O_CLOEXEC support in 2.6.38 — Antti Haapala -- Слава Україні, Aug 19 '13 at 05:42

score 12 · Accepted Answer · edited Aug 19 '13 at 04:37

It was decided that exposing O_CLOEXEC flag to fcntl(fd, F_GETFL) is security leak. Change was made by this commit in kernel 3.6-rc7:

commit c6f3d81115989e274c42a852222b80d2e14ced6f
Author: Al Viro <viro@zeniv.linux.org.uk>
Date:   Sun Aug 26 11:01:04 2012 -0400

don't leak O_CLOEXEC into ->f_flags

Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>

In other words, you should not have relied on O_CLOEXEC being visible in first place.

Antti Haapala -- Слава Україні · Answer 2 · 2013-08-19T04:09:17.170

2

The fcntl call parameter F_GETFD, the flag is FD_CLOEXEC and the O_CLOEXEC support appeared in 2.6.23. Read the manuals:

 File descriptor flags
   The following commands manipulate the flags associated with a file descriptor.
   Currently,  only one such flag is defined: FD_CLOEXEC, the close-on-exec flag.
   If the FD_CLOEXEC bit is 0, the file descriptor will  remain  open  across  an
   execve(2), otherwise it will be closed.

   F_GETFD (void)
          Read the file descriptor flags; arg is ignored.

   F_SETFD (int)
          Set the file descriptor flags to the value specified by arg.

edited Aug 19 '13 at 04:09

answered Aug 19 '13 at 03:45

Antti Haapala -- Слава Україні

129,958
22
279
321

OP said he succeeds in kernel 2.6 but fails on 3.8/3.9 – Yu Hao Aug 19 '13 at 03:47
1

The test fails when running on kernel 3.8 that obviously supports O_CLOEXEC. Please read the question. – Ivan Efremov Aug 19 '13 at 03:50
1

This answer is correct inasmuch as the *right* way to get the `CLOEXEC` status is to use `F_GETFD` and test for `FD_CLOEXEC`, because `CLOEXEC` is a flag that applies to each file descriptor, rather than the underlying open file. That doesn't explain why the ABI for `F_GETFL` apparently changed, though. – caf Aug 19 '13 at 03:53
Could you please cite the spec describing the _right_ way? From manuals I see that the test is perfectly _right_. – Ivan Efremov Aug 19 '13 at 03:59
2

No, it is never documented like that. `F_GETFL` is just the open flags of the file; someone decided that the bit should be taken out as it does not affect the opened file but the file descriptor only. That is why it is not documented. – Antti Haapala -- Слава Україні Aug 19 '13 at 04:12
Furthermore, F_GETFL seems to return whatever was given to the open, less filtered flags, even ignored ones. – Antti Haapala -- Слава Україні Aug 19 '13 at 04:35
Thus it was never a reliable way to see if a flag was supported. – Antti Haapala -- Слава Україні Aug 19 '13 at 05:05

score 2 · Answer 3 · answered Sep 26 '14 at 22:33

2

You are doing it wrong. You should do by this way:

int ret = fcntl(fd, F_GETFD);
if (ret & FD_CLOEXEC) {
...
}

answered Sep 26 '14 at 22:33

socketpair

1,893
17
15

open() doesn't set O_CLOEXEC flag

3 Answers3