New system calls: pidfd_open() and close_range()

Primarily: because they don't need an efficient way to do it. They can close file descriptors once at startup and thereafter make sure to use CLOEXEC to prevent file descriptor leakage. That works fine and doesn't encourage bad practices in the rest of userspace. But more generally...

It's obviously hard to argue against "we should do more sandboxing". But I fall back to the analogy to environment variables: If we shouldn't clear the environment before running the program, then we shouldn't close all file descriptors before running it. Browser Javascript sandboxes are totally closed off from the rest of the system - they certainly don't need environment variables, and they wouldn't benefit from file descriptors either. So it's fine to clear the environment and close all fds before running them.

Certainly I think we should move towards a world where processes can't access things they haven't somehow been given access to. But I don't think we should make every process like a browser Javascript sandbox, and be totally closed off from the system. There are many things that are implicitly inherited in Linux - the root directory, the current working directory, all the namespaces, tons of things. Most of those should be removed or reworked, because they're easy to mess up and can't easily be controlled, and most of them can't even be changed without privileges. But many parts of Unix are still useful, and shouldn't be removed. Environment variables shouldn't be removed, and the possibility of implicit inheritance of file descriptors shouldn't be removed. Otherwise we'll inevitably end up reinventing those, slowly and painfully.

>Plus, it seems to me that leaking internal file descriptors into spawned subprocesses is unhygenic, asking for trouble, and should not be the default.

I agree! Thankfully, there is already a way to prevent this: CLOEXEC. You don't need close_range to avoid leaking file descriptors into spawned subprocesses.

As I said in my original comment: CLOEXEC is the right way to stop to stop implicit inheritance of file descriptors, and I think it should be the default. Almost all file descriptors shouldn't be implicitly inherited into children - that would be massive resource leakage. But sometimes you *do* want to implicitly inherit a file descriptor and CLOEXEC gives you that option, because you can turn it off and inherit a file descriptor without having to explicitly tell your child that you're doing it. closefrom is wrong because there's no way to turn it off when some random glue program in the middle of the tree calls it, so it completely prevents implicit inheritance of file descriptors.