Re: process exit statuses (was: CVE-2023-51767)

[Simon McVittie <smcv () debian org>]

On Tue, 23 Sep 2025 at 05:21:13 +0200, Solar Designer wrote:
> some other system component (perhaps a library or the kernel)
> may also trigger a process exit with some code (and there are only 256
> to choose from)

There are slightly more than that at the wait() level, because "killed 
by signal N" is distinguishable from any normal exit status - although 
if the exiting executable is wrapped by an "adverb" like env(1), that 
will usually end up conflating "killed by signal N" with "exiting with 
status 128+N" and we're back to only having 256 choices.

I would say that best-practice for a component wanting to terminate a 
process abnormally should usually be to send it a fatal signal, rather 
than forcing it to _exit(). For example, assertion failures are better 
handled via abort() (SIGABRT) than as an exit status, and when the 
kernel terminates a process abnormally as a result of seccomp filters, 
resource limits or namespace-related constraints, it normally does so by 
killing the process with SIGSYS or SIGKILL.

For historical reasons libX11 and libdbus implement their optional 
exit-on-disconnection behaviour by exiting with status 1, but the 
equivalent code in GLib's D-Bus implementation uses raise(SIGTERM), 
which I think is a better implementation for exiting abnormally as a 
result of an external not-exactly-an-error condition.

    smcv