systemd --user instance tries to setup seccomp filters and fails.

[mbiebl]

systemd version the issue has been seen with

v238

Used distribution

Debian sid

Filed as downstream bug report
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=901313

The systemd --user instance apparently tries to setup seccomp filters and fails. The result is that the journal is flodded with messages like

Jun 11 17:24:42 jidanni6 systemd[230]: Failed to add rule for system call umount() / -10070, ignoring: Numerical argument out of domain
Jun 11 17:24:42 jidanni6 systemd[230]: Failed to add rule for system call profil() / -10040, ignoring: Numerical argument out of domain
Jun 11 17:24:42 jidanni6 systemd[230]: Failed to add rule for system call lock() / -10027, ignoring: Numerical argument out of domain
Jun 11 17:24:42 jidanni6 systemd[230]: Failed to add rule for system call gtty() / -10022, ignoring: Numerical argument out of domain
Jun 11 17:24:42 jidanni6 systemd[230]: Failed to add rule for system call prof() / -10039, ignoring: Numerical argument out of domain
Jun 11 17:24:42 jidanni6 systemd[230]: Failed to add rule for system call rtas() / -10187, ignoring: Numerical argument out of domain

This happens when debug logging is enabled.

[poettering]

Well, you asked for debug output, and you got debug output.

systemd's default seccomp filters list syscalls that are not available on all archs, and that's entirely OK. For example, i386 has umount() while x86-64 does not (it has umount2() instead). libseccomp returns EDOM for those syscalls. Which is fine to ignore, after all these system calls really don't exist on those archs.

We show these in the debug output so that developers can verify that only syscalls that really don't exist result in EDOM. Which in the case above is the case, hence there's really nothing strange here.

And if you wonder why we include those i386-only syscalls in our lists even if we are called for x86-64: we install syscall filters for i386, for x32 and for x86-64 on x86-64 systems, and thus we need to list the syscalls of all relevant ABIs. Also, listing all syscalls make the system behave more alike on all archs, and "systemd-analyze syscall-filter" will reflect the same data everywhere.

Hence, really, there's nothing to fix here. it's logged at debug level for a reason. If it was something relevant, it would be logged on a higher level.

[yuwata]

Also, this seems duplicate of #8790.

[mbiebl]

does it make sense to try and apply such seccomp filters for the systemd --user instance in the first place?

[poettering]

does it make sense to try and apply such seccomp filters for the systemd --user instance in the first place?

yes. seccomp works for unprivileged users too.