Bug 1774499 - mock: Use chroot mode by default
Summary: mock: Use chroot mode by default
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: mock
Version: rawhide
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Miroslav Suchý
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2019-11-20 12:30 UTC by Florian Weimer
Modified: 2019-11-21 08:26 UTC (History)
9 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-11-21 08:26:36 UTC
Type: Bug
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Bugzilla 1770154 0 unspecified CLOSED systemd: Default seccomp filter in systemd-spawn breaks userspace ABI 2021-02-22 00:41:40 UTC

Internal Links: 1770154

Description Florian Weimer 2019-11-20 12:30:15 UTC 
systemd-nspawn disables system calls in an apparently random fashion. See bug 1770154. This leads to needless package build failures and makes it unsuitable for use in mock.

Please switch to chroot mode by default to avoid these issues.
Comment 1 Miroslav Suchý 2019-11-20 12:52:03 UTC 
To be sure - it is sufficient to disable it only for fedora-rawhide-i386 config. Right?
Comment 2 Florian Weimer 2019-11-20 12:56:18 UTC 
No, the pidfd_open filter affects everyone. See bug 1774417 comment 2.

I'll ask around for a simple sandbox replacement which still gives us the obvious benefit of namespaces (such as TCP/UDP port isolation), without all the hassle.
Comment 3 Miroslav Suchý 2019-11-20 13:23:43 UTC 
A lot of people put a lot of effort to learn Mock to use systemd-nspawn. I am not a big fan of turning everything off. I think this should be fixed in systemd-nspawn instead of Mock.
Comment 5 Zbigniew Jędrzejewski-Szmek 2019-11-20 22:39:08 UTC 
It should be already fixed (in updates-testing for F31 and rawhide). Latest systemd update and libseccomp are needed.

It happened that the a bunch of syscalls were added to the kernel, and nobody happened to hit them until
now. As soon as the issue was reported, it was fixed. The fix is generally very simple, just adding a
line to a table.
Comment 6 Miroslav Suchý 2019-11-21 08:26:36 UTC 
Thank you @zbyszek. I think we can close this BZ then.
Note You need to log in before you can comment on or make changes to this bug.