The design of core dump handling in Linux leaves much to be desired. Among its several flaws, the biggest is that it is a global setting, accessible only by the root user. A proper design would either allow it to be isolated via namespace, or delegated to a reaper/subreaper process (in an opt-in fashion for back-compat). There has been discussion of the former idea [0] and even a submitted patch [1], but it seems like it never went anywhere.
[0]: https://groups.google.com/g/linux.kernel/c/hJLP3XcKKSY
[1]: https://mail-archive.com/linux-kernel@vger.kernel.org/msg107...
>For example, the core-dump handler is launched by the kernel as a user-mode helper, meaning that it runs fully privileged in the root namespace.
Why is it not run as a dedicated core dump user?
>the core-dump socket to a helper can be intercepted
There have been several vulnerabilities related to this feature of passing core files to a container. I question if this feature is actually worth it considering one probably wants to have shared infrastructure for crash reporting anyways.
Good to see CVEs driving design change I guess
This flurry of effort reminds me of that time in the '90s when I had the privilege of exploiting a core dump mishandling for real after a friend of mine forget the root password for his ISP's nameserver.
I'm having a hard time parsing this because I don't understand what "****" is supposed to mean in "**** API". Is it a "shit API" or "crap API", indicating that the API has problems? Is it a "damn API", which just indicates that the author of the quote is annoyed but there's nothing wrong with the API itself?
I assume it's meant to be the first meaning, that the API is bad? But the censorship honestly makes me a bit unclear.