5 ms·
I think the idea with that was it would lead to denial-of-service type situations where some process could leak a bunch of pidfds and then that would cause exha
by zxzax 5y ago
I think the idea with that was it would lead to denial-of-service type situations where some process could leak a bunch of pidfds and then that would cause exhaustion of pids everywhere else.
- Jasper_ 5y agoA process could also do that by spawning a bunch of processes if it wanted to.
- zxzax 5y agoNot really, most systems should set RLIMIT_NPROC to prevent that. If pidfds held onto the pid, it would create a new denial-of-service that allowed random other processes to keep zombie processes open, and the fix for it would actually allow you to circumvent that limit!
- Jasper_ 5y agoYou can also set RLIMIT_NOFILE to prevent the number of FDs the app can open if you're worried about it.
- zxzax 5y agoI don't think that would necessary solve it, since the maximum number you can have open is still RLIMIT_NPROC * RLIMIT_NOFILE, right? It seems it would still be a problem as long as it's greater than RLIMIT_NPROC. Edit: I suppose you could fix it as long as you could guarantee that NPROC * NOFILE * maxlogins < kernel.pid_max... but to me this is piling on more workarounds.
- a1369209993 5y agoIsn't this easily fixed by counting held processes via pidfd towards RLIMIT_NPROC? You'd get a rlimit error when calling pidfd_open, but it already returns EMFILE for RLIMIT_NOFILE, so that doesn't seem onerous unless you're trying to enforce exact numbers of processes rather than "less than some reasonable limit". Edit: note that pidfds holding same-uid processes have no effect (that process already belongs to your uid), and multiple processes holding a single foreign process only count once (that single foreign process is counted toward your NPROC, since it will stick around for pidfd even if its user kills it).