netfilter buglog - Dec 2016 - [Bug 1104] New: Use close on exec flags instead of fcntl

https://bugzilla.netfilter.org/show_bug.cgi?id=1104

            Bug ID: 1104
           Summary: Use close on exec flags instead of fcntl
           Product: iptables
           Version: CVS (please indicate timestamp)
          Hardware: x86_64
                OS: All
            Status: NEW
          Severity: enhancement
          Priority: P5
         Component: iptables
          Assignee: netfilter-buglog at lists.netfilter.org
          Reporter: g.gupta at samsung.com

Now in lateswt versions of glibc, close on exec flags are available for
file/socket open functions which are better than using fcntl.
Below is current usage of fcntl in iptables:
./libxtables/xtables.c: if (fcntl(procfile, F_SETFD, FD_CLOEXEC) == -1) {
./libxtables/xtables.c: if (fcntl(sockfd, F_SETFD, FD_CLOEXEC) == -1) {
./libiptc/libiptc.c:    if (fcntl(sockfd, F_SETFD, FD_CLOEXEC) == -1) {
./extensions/libxt_set.h:       if (fcntl(sockfd, F_SETFD, FD_CLOEXEC) == -1)

It can use O_CLOEXEC flag with open() system call & SOCK_CLOEXEC with
socket()
call instead of using fcntl.
Please let me know if patch is required.

Refer:
http://man7.org/linux/man-pages/man2/open.2.html
 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.

              Note that the use of this flag is essential in some
              multithreaded programs, because using a separate fcntl(2)
              F_SETFD operation to set the FD_CLOEXEC flag does not suffice
              to avoid race conditions where one thread opens a file
              descriptor and attempts to set its close-on-exec flag using
              fcntl(2) at the same time as another thread does a fork(2)
              plus execve(2).  Depending on the order of execution, the race
              may lead to the file descriptor returned by open() being
              unintentionally leaked to the program executed by the child
              process created by fork(2).  (This kind of race is in
              principle possible for any system call that creates a file
              descriptor whose close-on-exec flag should be set, and various
              other Linux system calls provide an equivalent of the
              O_CLOEXEC flag to deal with this problem.)

-- 
You are receiving this mail because:
You are watching all bug changes.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.netfilter.org/pipermail/netfilter-buglog/attachments/20161220/8d3242c9/attachment.html>