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

> 16.12.2020 09:41, 张翔 пишет:
> > # HG changeset patch
> > # User Zhang Xiang <hawkxiang.cpp@gmail.com
> > <mailto:hawkxiang.cpp@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@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
_______________________________________________
nginx-devel mailing list
nginx-devel@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-devel