21

Let say, from kernel 2.6 onwards.

I watch all the running processes on the system.

Are the PID of the children always greater than their parents' PIDs?

Is it possible to have special cases of "inversion"?

47

No, for the very simple reason that there is a maximum numerical value the PID can have. If a process has the highest PID, no child it forks can have a greater PID. The alternative to giving the child a lower PID would be to fail the fork() altogether, which wouldn't be very productive.

The PIDs are allocated in order, and after the highest one is used, the system wraps around to reusing the (free) lower ones, so you can get lower PIDs for a child in other cases too.

The default maximum PID on my system (/proc/sys/kernel/pid_max) is just 32768, so it's not hard to reach the condition where the wraparound happens.

$ echo $$
27468
$ bash -c 'echo $$'
1296
$ bash -c 'echo $$'
1297

If your system were to allocate PIDs randomly (like OpenBSD appears to do) instead of consecutively (like Linux), there would be two options. Either the random choice was made over the whole space of possible PIDs, in which case it would be obvious that a child's PID can be lower than the parent's. Or, the child's PID would be chosen by random from the values greater than the parent's PID, which would on average put it halfway between the parent's PID and the maximum. Processes forking recursively would then quickly reach the maximum and we'd be at the same point as mentioned above: a new fork would need to use a lower PID to succeed.

  • 3
    FWIW, there exists systems where the PIDs are allocated randomly (by default on OpenBSD for example), and I'm sure I've seen a similar PID allocation scheme on Linux as well (or at least seen one suggested). – Kusalananda Sep 4 '18 at 11:31
  • @Kusalananda, yeah, I think there's been a question about that on unix.SE, too. I don't have the time to dig it up, but as far as I remember, the patch for Linux that did random PID choosing was old and abandoned as unnecessary. It doesn't matter though: as long as there's a (relatively low) maximum PID, once it's used the choices are either to give a lower PID, or drop an error on the fork. – ilkkachu Sep 4 '18 at 11:36
  • 2
    @Massimo, the security aspect is discussed in this question on security.se: Do randomized PIDs bring more security? – ilkkachu Sep 4 '18 at 14:10
  • 1
    @RonJohn, well, I don't what values other Linuxes put there, but it's modifiable, you can set it to about 4 million (4194304, or 2^22) on 64-bit systems. (it's a number, not an amount of bytes) – ilkkachu Sep 5 '18 at 7:37
8

Also there exists the potential for security vulnerabilities using kernel notifications and forking yourself to avoid detection by a process table scan; this if done right results in your process having a lower PID and process tools not seeing the process in question.

http://cve.circl.lu/cve/CVE-2018-1121

procps-ng, procps is vulnerable to a process hiding through race condition. Since the kernel's proc_pid_readdir() returns PID entries in ascending numeric order, a process occupying a high PID can use inotify events to determine when the process list is being scanned, and fork/exec to obtain a lower PID, thus avoiding enumeration. An unprivileged attacker can hide a process from procps-ng's utilities by exploiting a race condition in reading /proc/PID entries. This vulnerability affects procps and procps-ng up to version 3.3.15, newer versions might be affected also.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.