Process container parent is the process used to start processes with a new
user namespace - e.g systemd-nspawn, runc, lxc, etc.
There is not standard way how to find such a process - or I do not know
about it - hence I have decided to find the first process in the parent
process hierarchy with a different mount namespace and different
/proc/self/root's inode.
I have decided for this criteria because in ABRT we take special care
only if the crashed process runs different code than installed on the
host. Other processes with namespaces different than PID 1's namespaces
are just processes running code shipped by the OS vendor and bug
reporting tools can get information about the provider of the code
without the need to deal with changed root and so on.
The macro determines the right length of a AF_UNIX "struct sockaddr_un" to pass to
connect() or bind(). It automatically figures out if the socket refers to an
abstract namespace socket, or a socket in the file system, and properly handles
the full length of the path field.
This macro is not only safer, but also simpler to use, than the usual
offsetof() + strlen() logic.
This moves the O_TMPFILE handling from the coredumping code into common library
code, and generalizes it as open_tmpfile_linkable() + link_tmpfile(). The
existing open_tmpfile() function (which creates an unlinked temporary file that
cannot be linked into the fs) is renamed to open_tmpfile_unlinkable(), to make
the distinction clear. Thus, code may now choose between:
a) open_tmpfile_linkable() + link_tmpfile()
b) open_tmpfile_unlinkable()
Depending on whether they want a file that may be linked back into the fs later
on or not.
In a later commit we should probably convert fopen_temporary() to make use of
open_tmpfile_linkable().
Followup for: #3065
Don't leave temporary files if the coredump service is aborted during
the operation
Yeah, these are temporary files that systemd-coredump needs while
processing the coredumps. Of course, if the coredump service is aborted
during the operation we better shouldn't leave those files around. This
is hence a bug to fix in our coredumping code.
See https://github.com/systemd/systemd/issues/2804#issuecomment-210578147
Another option is to simply use O_TMPFILE, and when it is not available
fall back to the current behaviour. After all, the files are cleaned up
eventually, through normal tmpfiles aging, and the offending file
systems are pretty exotic these days, or not in the upstream kernel.
See https://github.com/systemd/systemd/issues/2804#issuecomment-211496707
Let's add an extra-safety net and change UID/GID to the "systemd-coredump" user when processing coredumps from system
user. For coredumps of normal users we keep the current logic of processing the coredumps from the user id the coredump
was created under.
Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=87354
With this change processing/saving of coredumps takes the RLIMIT_CORE resource limit of the crashing process into
account, given the user control whether specific processes shall core dump or not, and how large to make the core dump.
Note that this effectively disables core-dumping for now, as RLIMIT_CORE defaults to 0 (i.e. is disabled) for all
system processes.
This reworks the coredumping logic so that the coredump handler invoked from the kernel only collects runtime data
about the crashed process, and then submits it for processing to a socket-activate coredump service, which extracts a
stacktrace and writes the coredump to disk.
This has a number of benefits: the disk IO and stack trace generation may take a substantial amount of resources, and
hence should better be managed by PID 1, so that resource management applies. This patch uses RuntimeMaxSec=, Nice=, OOMScoreAdjust=
and various sandboxing settings to ensure that the coredump handler doesn't take away unbounded resources from normally
priorized processes.
This logic is also nice since this makes sure the coredump processing and storage is delayed correctly until
/var/systemd/coredump is mounted and writable.
Fixes: #2286
Jakub Filak