Hello, Right.. So we can ignore the kernel parameter and sandboxing option here then. What could potentially override the coredump_filter in userspace? Is there any particular mechanism inside systemd that may do such a thing? Best, Daechir Sent with Proton Mail secure email. On Wednesday, January 10th, 2024 at 3:45 AM, Lennart Poettering <lennart@xxxxxxxxxxxxxx> wrote: > On Mo, 08.01.24 04:04, daechir (daechir@xxxxxxxxxxxxxx) 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@.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
Attachment:
publickey - daechir@protonmail.com - 0x16D272E3.asc
Description: application/pgp-keys
Attachment:
signature.asc
Description: OpenPGP digital signature
