Hacker News Reader

Comment by _d7dt | Hacker News Reader

Something else that doesn't often get brought up here is that kill(2) itself is an unfixable race condition waiting to happen. It's only safe to use that to signal direct child processes. In Linux, programs should be using the newer pidfd_send_signal syscall in almost every case where they would otherwise use kill(2).

Edit: waitpid is also similarly broken and unfixable for a lot of the same reasons as signals, pidfds and waitid(P_PIDFD, ...) should be replacing most uses of that as well.

View on HN

Could you explain what the problem is, or provide a link?

The primary problem is that a process could exit, and the pid might be recycled, so you kill() the wrong process.

I've always felt like it should be the case that as long as a pidfd for that process is open, the pid doesn't get recycled, so you could open the pidfd and then use kill safely, then close it later. Means you wouldn't need a whole bunch of new syscalls.

Unfortunately, it seems like this idea was rejected during the introduction of pidfd.

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.

A process could also do that by spawning a bunch of processes if it wanted to.

Not 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!

You can also set RLIMIT_NOFILE to prevent the number of FDs the app can open if you're worried about it.

I 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.

Isn'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).

This is a (rare?) instance where I would say Win32 gives you some remedy over POSIX. On Windows, you can open a handle and deal with that, rather than a pid. Once the handle is open, it isn't subject to this recycling problem.

However if opening a handle based on pid you may want to double-check that the handle matches your expectation before using it, since that would be prone to the same race.

This is actually what pidfd does on linux, you get a handle to the process that lets you interact with it in that same manner. Once the process exits the handle gets closed and all the operations will report an error even if you have a recycled pid

Not that it matters much these days, but do note that pidfd is a Linux concept, not a posix one. It's also a fairly recent one and it'll be a number of years before many people can use it even still. Windows by comparison has had a solution for white some time.

I dont care much for Windows, but I would argue that it's well architected compared to nix in many regards.

The classic ABA problem, then.

https://en.wikipedia.org/wiki/ABA_problem

Had no idea about this! Thank you. Now I'm starting to understand undefined behavior safety is such a walled garden. All sorts of snakes might be lurking beneath.

This might be naive of me, but isn't this in a way fixed by systemd service handling? Assuming the process in question is, in fact, handled as a service of course.

Correct.

The issue is solved in any service manager as long as the service doesn't fork, when you are the parent process you can ensure that you don't reap the child before sending a signal.

Once the service forks then it becomes a problem. If you use cgroups it can be solved separately with the cgroup freezer, but there are still some open issues with this in systemd: https://github.com/systemd/systemd/issues/13101

The problem was discussed quite a lot around the introduction of pidfds:

https://lwn.net/Articles/773459/

https://lwn.net/Articles/784831/

In essence it's a classic TOCTTOU.

The waitpid() call isn't quite as broken; I think there are only races there if there is any chance other parts of your process call waitpid() on the same pid and it gets reaped twice.

Under normal operation (pid returned from fork, waitpid used in one spot until the child exits, no odd sigchild shenanigans), I don't think waitpid() has any races.

Am I missing anything?

The issue I know of is, you cannot really use waitpid(-1, ...) in the same process as waitpid(<pid>, ...), as it would create a race condition on which call consumes the pid first. You can mitigate it in some programs by doing a lookup after the waitpid(-1, ...), but still it's not really reliable for libraries to spawn child processes and use that function. See for example the notes here: https://developer.gnome.org/glib/stable/glib-The-Main-Event-...

If you need to multiplex a wait for multiple processes, it's safer to use epoll with several pidfds. But you still eventually may need to call waitid(-1, ...) to reap any forked processes, and there really is no good way around that.

Reply on news.ycombinator.com