New system calls: pidfd_open() and close_range()

Posted May 24, 2019 12:49 UTC (Fri) by mezcalero (subscriber, #45103)
In reply to: New system calls: pidfd_open() and close_range() by Sesse
Parent article: New system calls: pidfd_open() and close_range()

Well, for stdin/stdout/stderr that'll work, but it falls apart if the fds you want to keep and maybe later rearrange are already in the range you want to rearrange them to... The socket activation protocol systemd implements (i.e. LISTEN_FDS=) supports large numbers of fds, and systemd might create them a long time before actually activating things, hence they likely are in the range we want to move fds to.

New system calls: pidfd_open() and close_range()

Posted May 30, 2019 8:44 UTC (Thu) by mina86 (guest, #68442) [Link] (4 responses)

int close_except(int *fds_to_keep, size_t n) {
    qsort(fds_to_keep, n, sizeof *fds_to_keep, int_cmp);
    int fd = 0;
    for (size_t i = 0; i < n; ++i)
        if (fds_to_keep[i] != fd) dup2(fds_to_keep[i], fd++);
    return close_range(fd, INT_MAX);
}

Handling of EBADF and EINTR left as exercise to the reader.

New system calls: pidfd_open() and close_range()

Posted May 30, 2019 10:31 UTC (Thu) by Jandar (subscriber, #85683) [Link] (3 responses)

> Handling of EBADF and EINTR left as exercise to the reader.

And the important exercise is fixing the bug ;-). The fd's have to be moved back to their original value.

Closing every fd I don't know about is only a band-aid to fix buggy software (own or 3rd part library). The correct solution is using CLOEXEC and is available for ages.

New system calls: pidfd_open() and close_range()

Posted May 30, 2019 10:49 UTC (Thu) by mina86 (guest, #68442) [Link]

> And the important exercise is fixing the bug ;-). The fd's have to be moved back to their original value.

Or start referring to the file descriptors by their new numbers (though even then the function lacks a way to communicate all the remappings) to save on bunch of syscalls.

New system calls: pidfd_open() and close_range()

Posted Sep 7, 2019 17:59 UTC (Sat) by ceplm (subscriber, #41334) [Link] (1 responses)

> Closing every fd I don't know about is only a band-aid to fix buggy software (own or 3rd part library). The correct solution is using CLOEXEC and is available for ages.

No, it is useful also for programs where the author doesn’t have full control. See https://bugs.python.org/issue11284. I could have switch all Python open() calls to use CLOEXEC (that’s essentially what happened in Python 3.2 as an implementation of https://www.python.org/dev/peps/pep-0446/), but it doesn’t save me from C extensions which just use open(2) with default values and create inheritable file descriptors on POSIX platforms.

And walking through /proc/self/fd/ is horribly slow (think about FreeBSD’s MAXFD=655000), and mostly not async signal safe.

New system calls: pidfd_open() and close_range()

Posted Sep 14, 2019 20:54 UTC (Sat) by Jandar (subscriber, #85683) [Link]

There are libraries (I have encountered one) opening a file-descriptor which has to remain open across exec to be used by the same library in (grand)child processes.

Mangling with unknown resources is never good practice but maybe as I said: a band-aid to fix buggy software. The C extension of your example is such buggy software you are applying a band-aid to.

I hope I never see close_range() in production-code. Using it is the confession one has given up on producing/using good software.