Rethinking race-free process signaling

Posted Apr 9, 2019 16:39 UTC (Tue) by quotemstr (subscriber, #45331)
In reply to: Rethinking race-free process signaling by nix
Parent article: Rethinking race-free process signaling

> fds ('loop over lots of fds, close() them all, and hope you got them all' is still a thing a huge number of processes do),

I have zero qualms about breaking programs that are so obviously broken themselves. You don't free resources you didn't create: that's a rule for any system, not just unix. Just no. Let's no enable programs that break this rule.

Rethinking race-free process signaling

Posted Apr 9, 2019 19:50 UTC (Tue) by roc (subscriber, #30627) [Link]

Applications that launch a securely sandboxed child process need to do this in the child process before they exec. Leaking a file descriptor across the sandbox boundary would be devastating.

Rethinking race-free process signaling

Posted Apr 13, 2019 15:01 UTC (Sat) by nix (subscriber, #2304) [Link] (1 responses)

The problem is that a loop closing the first 1024 fds before exit is incredibly common. Almost everything written before O_CLOEXEC became commonplace does that. Are you willing to break everything written before then? I'm certainly not. People are using those programs.

Rethinking race-free process signaling

Posted Apr 13, 2019 15:58 UTC (Sat) by quotemstr (subscriber, #45331) [Link]

It's less of a problem when the FDs are closed just before exec. Fewer programs randomly close all FDs in steady-state execution, unforked.