accept4() support SOCK_CLOEXEC flag

[Ranier Vilela]

Em qua., 16 de dez. de 2020 às 10:14, Vladimir Homutov <vl at nginx.com>
escreveu:

> 16.12.2020 09:41, 张翔 пишет:
> > # HG changeset patch
> > # User Zhang Xiang <hawkxiang.cpp at gmail.com
> > <mailto:hawkxiang.cpp at gmail.com>>
> > # Date 1608099124 -28800
> > #      Wed Dec 16 14:12:04 2020 +0800
> > # Node ID a685d9c04acdb4ec71fd9f176415917c217af630
> > # Parent  82228f955153527fba12211f52bf102c90f38dfb
> > Mail: accept4() support SOCK_CLOEXEC flag
> >
> > The close-on-exec flag on the new FD can be set via SOCK_CLOEXEC
> >
> > diff -r 82228f955153 -r a685d9c04acd auto/unix
> > --- a/auto/unix Tue Dec 15 17:41:39 2020 +0300
> > +++ b/auto/unix Wed Dec 16 14:12:04 2020 +0800
> > @@ -510,7 +510,7 @@
> >   ngx_feature_incs="#include <sys/socket.h>"
> >   ngx_feature_path=
> >   ngx_feature_libs=
> > -ngx_feature_test="accept4(0, NULL, NULL, SOCK_NONBLOCK)"
> > +ngx_feature_test="accept4(0, NULL, NULL, SOCK_NONBLOCK | SOCK_CLOEXEC)"
> >   . auto/feature
> >
> >   if [ $NGX_FILE_AIO = YES ]; then
> > diff -r 82228f955153 -r a685d9c04acd src/event/ngx_event_accept.c
> > --- a/src/event/ngx_event_accept.c      Tue Dec 15 17:41:39 2020 +0300
> > +++ b/src/event/ngx_event_accept.c      Wed Dec 16 14:12:04 2020 +0800
> > @@ -57,7 +57,7 @@
> >
> >   #if (NGX_HAVE_ACCEPT4)
> >           if (use_accept4) {
> > -            s = accept4(lc->fd, &sa.sockaddr, &socklen, SOCK_NONBLOCK);
> > +            s = accept4(lc->fd, &sa.sockaddr, &socklen, SOCK_NONBLOCK |
> > SOCK_CLOEXEC);
> >           } else {
> >               s = accept(lc->fd, &sa.sockaddr, &socklen);
> >           }
> >
> > _______________________________________________
> > nginx-devel mailing list
> > nginx-devel at nginx.org
> > http://mailman.nginx.org/mailman/listinfo/nginx-devel
> >
>
> just realized you are talking about accepted sockets.
> Why do you think it is useful? Normally we don't fork workers and don't
> exec anything.
>
Sorry for meddling.
While we wait for a response, I would like to include just for help.

*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)
<https://man7.org/linux/man-pages/man2/fcntl.2.html> *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) <https://man7.org/linux/man-pages/man2/fcntl.2.html>
              *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)
<https://man7.org/linux/man-pages/man2/fcntl.2.html> at the same time
as another thread does a fork(2)
<https://man7.org/linux/man-pages/man2/fork.2.html>
              plus execve(2)
<https://man7.org/linux/man-pages/man2/execve.2.html>.  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)
<https://man7.org/linux/man-pages/man2/fork.2.html>.  (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.)

Ranier Vilela
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx-devel/attachments/20201216/73ed8c55/attachment.htm>