I don't see a fix for systemd's LP: #1918696 in the systemd xenial SRU in the queue - is xenial unaffected by the ppc64el test issues? Also, SRUs for focal and groovy had some additional systemd changes besides libseccomp to get things working - are those also not needed in xenial?
I'd like someone to make sure that's the case. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1891810 Title: Backport 2.5.1 to fix missing openat2 syscall, causing problems for fuse-overlayfs in nspawn containers Status in libseccomp package in Ubuntu: Fix Released Status in systemd package in Ubuntu: New Status in libseccomp source package in Xenial: Fix Committed Status in systemd source package in Xenial: New Status in libseccomp source package in Bionic: Fix Committed Status in systemd source package in Bionic: Fix Committed Status in libseccomp source package in Focal: Fix Committed Status in systemd source package in Focal: Fix Committed Status in libseccomp source package in Groovy: Fix Committed Status in systemd source package in Groovy: New Status in libseccomp source package in Hirsute: Fix Released Status in systemd source package in Hirsute: New Bug description: [Impact] The version of libseccomp2 in X/B/F/G does not know about the openat2 syscall. As such applications that use libseccomp cannot specify a system-call filter against this system-call and so it cannot be mediated. [Test Plan] This can be tested by simply running scmp_sys_resolver from the seccomp binary package and specifying this system-call: Existing behaviour: $ scmp_sys_resolver openat2 -1 Expected behaviour: $ scmp_sys_resolver openat2 437 (Note this value will be different on other architectures) [Where problems could occur] In version 2.5.1 of libseccomp which adds this new system-call, changes were also made in the way the socket system-call is handled by libseccomp on PPC platforms - this resulted in a change in the expected behaviour and so this has already been noticed and a fix is required for the systemd unit tests as a result https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1918696 There was also a similar change for s390x but so far no regressions have been observed as a result as systemd already expected that behaviour from libseccomp, it was only PPC that was missing. In the event that a regression is observed however, we can easily either patch the affected package to cope with the new behaviour of this updated libseccomp since in each case the change in behaviour only affects a few system calls on particular architectures, or we can revert this update. [Other Info] * As usual thorough testing of this update has been performed both manually via the QA Regression Testing scripts, and via the autopkgtest infrastructure against packages in the Ubuntu Security Proposed PPA https://launchpad.net/~ubuntu-security- proposed/+archive/ubuntu/ppa/ with results seen https://people.canonical.com/~platform/security-britney/current/ I have attached debdiffs of the prepared updates which are also sitting in the Ubuntu Security Proposed PPA. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/libseccomp/+bug/1891810/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp