8 ms·

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

by taviso 5y ago

Jasper_ 5y ago
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.
- 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 ago
    A process could also do that by spawning a bunch of processes if it wanted to.
    - zxzax 5y ago
      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!
      - Jasper_ 5y ago
        You can also set RLIMIT_NOFILE to prevent the number of FDs the app can open if you're worried about it.
        zxzax 5y ago
        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.
      - a1369209993 5y ago
        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).
hnarn 5y ago
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.
- Quekid5 5y ago
  Correct.
- zxzax 5y ago
  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 https://github.com/systemd/systemd/issues/13101
asveikau 5y ago
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.
- simcop2387 5y ago
  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
  - surajrmal 5y ago
    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.
- surajrmal 5y ago
  I dont care much for Windows, but I would argue that it's well architected compared to nix in many regards.
MaxBarraclough 5y ago
The classic ABA problem, then. https://en.wikipedia.org/wiki/ABA_problem https://en.wikipedia.org/wiki/ABA_problem
- orthonormal 5y ago
  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.

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

by taviso 5y ago

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.

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 ago
  A process could also do that by spawning a bunch of processes if it wanted to.
  - zxzax 5y ago
    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!
    - Jasper_ 5y ago
      You can also set RLIMIT_NOFILE to prevent the number of FDs the app can open if you're worried about it.
      - zxzax 5y ago
        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.
    - a1369209993 5y ago
      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).

hnarn 5y ago

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.

Quekid5 5y ago
Correct.
zxzax 5y ago
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 https://github.com/systemd/systemd/issues/13101

asveikau 5y ago

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.

simcop2387 5y ago
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
- surajrmal 5y ago
  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.
surajrmal 5y ago
I dont care much for Windows, but I would argue that it's well architected compared to nix in many regards.

MaxBarraclough 5y ago

The classic ABA problem, then. https://en.wikipedia.org/wiki/ABA_problem https://en.wikipedia.org/wiki/ABA_problem

orthonormal 5y ago
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.