Bug 1770154 - systemd: Default seccomp filter in systemd-spawn breaks userspace ABI
Summary: systemd: Default seccomp filter in systemd-spawn breaks userspace ABI
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: systemd
Version: rawhide
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: systemd-maint
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 1771319 (view as bug list)
Depends On:
Blocks: 1769299
TreeView+ depends on / blocked
 
Reported: 2019-11-08 10:32 UTC by Paul Howarth
Modified: 2019-11-23 09:38 UTC (History)
19 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-11-23 01:31:02 UTC
Type: Bug


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Bugzilla 1774499 0 unspecified CLOSED mock: Use chroot mode by default 2021-02-22 00:41:40 UTC

Internal Links: 1774499

Description Paul Howarth 2019-11-08 10:32:17 UTC
Description of problem:
Trying to build anything with rawhide i386 using mock locally results in failure due to tar being unable to set timestamps of extracted files, e.g.

Finish: build setup for perl-Perl6-Caller-0.100-18.fc30.src.rpm
Start: rpmbuild perl-Perl6-Caller-0.100-18.fc30.src.rpm
Building target platforms: i686
Building for target i686
setting SOURCE_DATE_EPOCH=1573084800
Executing(%prep): /bin/sh -e /var/tmp/rpm-tmp.eR7R1s
+ umask 022
+ cd /builddir/build/BUILD
+ cd /builddir/build/BUILD
+ rm -rf Perl6-Caller-0.100
+ /usr/bin/tar -xof -
+ /usr/bin/gzip -dc /builddir/build/SOURCES/Perl6-Caller-0.100.tar.gz
/usr/bin/tar: Perl6-Caller-0.100/Build.PL: Cannot utime: Operation not permitted
/usr/bin/tar: Perl6-Caller-0.100/Changes: Cannot utime: Operation not permitted
/usr/bin/tar: Perl6-Caller-0.100/Makefile.PL: Cannot utime: Operation not permitted
/usr/bin/tar: Perl6-Caller-0.100/MANIFEST: Cannot utime: Operation not permitted
/usr/bin/tar: Perl6-Caller-0.100/META.yml: Cannot utime: Operation not permitted
/usr/bin/tar: Perl6-Caller-0.100/README: Cannot utime: Operation not permitted
/usr/bin/tar: Perl6-Caller-0.100/lib/Perl6/Caller.pm: Cannot utime: Operation not permitted
/usr/bin/tar: Perl6-Caller-0.100/lib/Perl6: Cannot utime: Operation not permitted
/usr/bin/tar: Perl6-Caller-0.100/lib: Cannot utime: Operation not permitted
/usr/bin/tar: Perl6-Caller-0.100/t/00-load.t: Cannot utime: Operation not permitted
/usr/bin/tar: Perl6-Caller-0.100/t/10-caller.t: Cannot utime: Operation not permitted
/usr/bin/tar: Perl6-Caller-0.100/t: Cannot utime: Operation not permitted
/usr/bin/tar: Perl6-Caller-0.100/xt/pod-coverage.t: Cannot utime: Operation not permitted
/usr/bin/tar: Perl6-Caller-0.100/xt/pod.t: Cannot utime: Operation not permitted
/usr/bin/tar: Perl6-Caller-0.100/xt: Cannot utime: Operation not permitted
/usr/bin/tar: Perl6-Caller-0.100: Cannot utime: Operation not permitted
/usr/bin/tar: Exiting with failure status due to previous errors
error: Bad exit status from /var/tmp/rpm-tmp.eR7R1s (%prep)

Version-Release number of selected component (if applicable):
glibc-2.30.9000-17.fc32

How reproducible:
Every time for me (F-30 x86_64 builder), but not seeming to affect koji builds?

Excluding glibc-2.30.9000-17.fc32 so that mock picks up glibc-2.30.9000-16.fc32 from a local mirror I have makes this problem go away for me.

Any ideas why this might be affecting me but not builds in koji?

Comment 1 Florian Weimer 2019-11-08 11:06:46 UTC
I think this is a broken seccomp filter in systemd-nspawn. See bug 1769299, which is a similar issue.

Comment 2 Zbigniew Jędrzejewski-Szmek 2019-11-08 12:00:28 UTC
Did glibc change the details of utime implementation?
systemd-nspawn allows utime and friends by default.

$ systemd-analyze syscall-filter @file-system|grep utime
    futimesat
    utime
    utimensat
    utimes

Comment 3 Zbigniew Jędrzejewski-Szmek 2019-11-08 12:02:43 UTC
FWIW, perl-Perl6-Caller builds fine in mock here with glibc-2.30.9000-17.fc32.x86_64.

But I have fairly old hardware, e.g. it doesn't support pkeys. I'm not saying that it's
relevant, but it might be, if #1769299 is actually related.

Comment 4 Florian Weimer 2019-11-08 12:20:54 UTC
(In reply to Zbigniew Jędrzejewski-Szmek from comment #2)
> Did glibc change the details of utime implementation?

Yes, because utime is an obsolete system call. The current kernel interface is utimensat_time64. New 32-bit architectures do not even provide the utime system call.

(In reply to Zbigniew Jędrzejewski-Szmek from comment #3)
> But I have fairly old hardware, e.g. it doesn't support pkeys. I'm not
> saying that it's
> relevant, but it might be, if #1769299 is actually related.

The failure is visible with and without pkeys because applications expect ENOSYS and apply a fallback, but not EPERM. glibc will use utime if utimensat_time64 fails with ENOSYS, but not in the case of EPERM.

Comment 5 Zbigniew Jędrzejewski-Szmek 2019-11-08 13:13:26 UTC
https://github.com/systemd/systemd/pull/13975

Comment 6 Paul Howarth 2019-11-08 14:26:35 UTC
(In reply to Zbigniew Jędrzejewski-Szmek from comment #3)
> FWIW, perl-Perl6-Caller builds fine in mock here with
> glibc-2.30.9000-17.fc32.x86_64.

My failing builds were on i386 because they're using the koji buildroot and picked up the updated glibc, which isn't in my mirror for x86_64 yet.

Is there something I can add in a systemd unit file to allow the additional system calls when mock (or anyone else) calls nspawn (as a workaround)?

Comment 7 Zbigniew Jędrzejewski-Szmek 2019-11-08 14:34:36 UTC
mock doesn't use a unit file I think. Adding
--system-call-filter=utimensat_time64 in config_opts['nspawn_args'] in /etc/mock/site-defaults.cfg should work.

Comment 8 Florian Weimer 2019-11-08 14:36:55 UTC
I suppose you could tweak mock with these options:

# Mock uses systemd-nspawn(1) by default. When use_nspawn is set to False,
# simple os.chroot() is used instead.
# config_opts['use_nspawn'] = True
# Additional args for nspawn
# config_opts['nspawn_args'] = ['--capability=cap_ipc_lock']

You probably have to switch to chroot mode because of this:

“
Note that systemd-nspawn always implements a system call whitelist (as
opposed to a blacklist), and this command line option hence adds or
removes entries from the default whitelist, depending on the "~"
prefix.
”

So there does not seem to be a way to enable system calls that systemd-nspawn knows nothing about. 8-(

Comment 9 Florian Weimer 2019-11-12 08:04:59 UTC
*** Bug 1771319 has been marked as a duplicate of this bug. ***

Comment 10 Miro Hrončok 2019-11-20 12:24:15 UTC
We have a related problem in Python.

https://bugs.python.org/issue38692#msg357054
https://bugzilla.redhat.com/show_bug.cgi?id=1774417#c2

Is there a way to adapt the mock config to permit pidfd_open?

I've tried to put this to my ~/.config/mock.cfg:

  config_opts['nspawn_args'] = ['--capability=cap_ipc_lock', '--system-call-filter=pidfd_open']

But it didn't help.

Comment 11 Florian Weimer 2019-11-20 12:28:04 UTC
(In reply to Miro Hrončok from comment #10)
> We have a related problem in Python.
> 
> https://bugs.python.org/issue38692#msg357054
> https://bugzilla.redhat.com/show_bug.cgi?id=1774417#c2
> 
> Is there a way to adapt the mock config to permit pidfd_open?
> 
> I've tried to put this to my ~/.config/mock.cfg:
> 
>   config_opts['nspawn_args'] = ['--capability=cap_ipc_lock',
> '--system-call-filter=pidfd_open']
> 
> But it didn't help.

Switching to chroot mode should help. systemd-nspawn in its current state is not useful for building packages. I will file a mock bug requesting this change.

Comment 12 Miro Hrončok 2019-11-20 12:42:37 UTC
> Switching to chroot mode should help. 

It does.

Comment 13 Zbigniew Jędrzejewski-Szmek 2019-11-20 15:10:26 UTC
cap_ipc_lock is necessary to call mlock() above the limit specified with ulimit -l.
Giving that privilege to the container payload would amount to allowing it to lock the
host machine. I don't think this is a good idea. I would expect that the python
test suite can pass with the default locked memory limit in place.

pidfd_open is a new syscall that needed to be added to a whitelist, and it is now
allowed with systemd-234.4-1-fc31.

Does the build still fail with the updated systemd?

Comment 14 Miro Hrončok 2019-11-20 15:57:50 UTC
> Does the build still fail with the updated systemd?

Yes.

Comment 15 Zbigniew Jędrzejewski-Szmek 2019-11-20 19:34:42 UTC
This also needs an updated libseccomp. I started a build for rawhide and F31 now.

Comment 16 Fedora Update System 2019-11-20 22:33:39 UTC
FEDORA-2019-bdf85066b7 has been submitted as an update to Fedora 31. https://bodhi.fedoraproject.org/updates/FEDORA-2019-bdf85066b7

Comment 17 Fedora Update System 2019-11-21 02:27:34 UTC
libseccomp-2.4.2-1.fc31 has been pushed to the Fedora 31 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2019-bdf85066b7

Comment 18 Fedora Update System 2019-11-23 01:31:02 UTC
libseccomp-2.4.2-1.fc31 has been pushed to the Fedora 31 stable repository. If problems still persist, please make note of it in this bug report.

Comment 19 Paul Howarth 2019-11-23 09:38:53 UTC
When I originally raised this bug I set the release to Rawhide because I thought it was an issue with the glibc update in Rawhide affecting mock builds. Since it's actually an issue with the build environment, this F-31 update is not going to fix things for me because I'm still on F-30 at the moment. At least I have the workaround of not using nspawn.


Note You need to log in before you can comment on or make changes to this bug.