[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <aNJ5lMEj4etE2n7M@remnant.pseudorandom.co.uk>
Date: Tue, 23 Sep 2025 11:42:28 +0100
From: Simon McVittie <smcv@...ian.org>
To: oss-security@...ts.openwall.com
Subject: Re: process exit statuses (was: CVE-2023-51767)
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
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
