[systemd-devel] Potential systemd CoredumpFilter sandboxing issue
Lennart Poettering
lennart at poettering.net
Wed Jan 10 08:45:20 UTC 2024
On Mo, 08.01.24 04:04, daechir (daechir at protonmail.com) wrote:
> Hello again,
> Thanks for fixing the utmp build issue from Nov 2023. I lost the email and couldn't figure out how to write to it.
>
> I found another issue that seems to be a bit more complicated. I'll try to describe it as best I can.
>
> When booting with the kernel parameter coredump_filter=0x0, all
> processes should read coredump_filter (at /proc/*/coredump_filter)
> as 00000000, or private-anonymous. This behavior works as
> intended. However, when specifying this kernel parameter, and also
> setting the systemd sandboxing option
> CoredumpFilter=private-anonymous, some services still tend to ignore
> or overwrite this value. I have found with v255 that
> /usr/lib/systemd/systemd --user is one such example, or
> user at .service which sets its /proc/*/coredump_filter to 00000001
> instead.
As per kernel docs the kernel command line option only sets the
*default*, i.e. userspace can override it. So the behaviour works as
intended?
Quoting kernel docs:
coredump_filter=
[KNL] Change the default value for
/proc/<pid>/coredump_filter.
> Am I wrong in understanding that private-anonymous usually maps to 00000000?
> Also, wouldn't 00000001 show something like coredump_filter=0x01 or CoredumpFilter=shared-anonymous?
I cannot parse this.
Lennart
--
Lennart Poettering, Berlin
More information about the systemd-devel
mailing list