Gregory's ServerWith v257 there's now a knob to address this situation too. systemd-coredump can now be configured (opt-in!) so that it will try to process coredumps of containers *on the host*. If you set EnterNamespace=yes in coredump.conf it will acquire access to the container's mount tree, mount it within its own private mount namespace to some special location, and then run coredump processing on that – while being part of the host runtime in almost all ways.
|
2 comments
 …here that comes from a differently trusted environment (the container payload) on the host. While we try to lock things down via sandboxing knobs, this nevertheless is not riskless. Because of that it's an opt-in thing, and it would be wise to enable this only if you sufficiently trust your container payloads. |
In many situations this new feature should be "good enough" to extract stack traces from containers, but of course it's not going to be able to fully address the fact that containers and host typically are built with different compiler/debugging settings, i.e. that the coredump processing and the coredump payload originate from different vendors with all the differences in generation this brings.
And of course, the security angle deserves attention: we are processing untrusted data…