Bug 1770154
Summary: | systemd: Default seccomp filter in systemd-spawn breaks userspace ABI | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Paul Howarth <paul> |
Component: | systemd | Assignee: | systemd-maint |
Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | unspecified | Docs Contact: | |
Priority: | unspecified | ||
Version: | rawhide | CC: | agk, aoliva, arjun.is, codonell, dj, fweimer, law, lnykryn, mfabian, mhroncok, msekleta, pfrankli, praiskup, rth, siddhesh, ssahani, s, systemd-maint, zbyszek |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | If docs needed, set a value | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2019-11-23 01:31:02 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: | |||
Bug Depends On: | |||
Bug Blocks: | 1769299 |
Description
Paul Howarth
2019-11-08 10:32:17 UTC
I think this is a broken seccomp filter in systemd-nspawn. See bug 1769299, which is a similar issue. 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 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. (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. (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)? 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. 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-( *** Bug 1771319 has been marked as a duplicate of this bug. *** 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. (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. > Switching to chroot mode should help.
It does.
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? > Does the build still fail with the updated systemd?
Yes.
This also needs an updated libseccomp. I started a build for rawhide and F31 now. FEDORA-2019-bdf85066b7 has been submitted as an update to Fedora 31. https://bodhi.fedoraproject.org/updates/FEDORA-2019-bdf85066b7 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 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. 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. |