When HAVE_LINUX_LANDLOCK is detected at build-time, `xz` binary uses this feature for sandboxing. This though breaks Fedora Mock builds on hosts that do not support LANDLOCK, e.g., as reported on C9S: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/BTKQUURKMQDI6DAUQJRNH5NPPC3G6IA7/ XZ could automatically fallback to "no sandboxing", or there could be something like --no-sandbox (runtime option). But until then, it could be acceptable to disable sandboxing? Reproducible: Always
(In reply to Pavel Raiskup from comment #0) > When HAVE_LINUX_LANDLOCK is detected at build-time, `xz` binary > uses this feature for sandboxing. > > This though breaks Fedora Mock builds on hosts that do not support > LANDLOCK, e.g., as reported on C9S: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/ > thread/BTKQUURKMQDI6DAUQJRNH5NPPC3G6IA7/ This is what has also broken the openscanhub checks https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/33SPZP6EN57GPK4B2TE3RDZBZOBMANXA/ It will also break people who are using podman/docker to run Fedora containers on a RHEL-9 host. > XZ could automatically fallback to "no sandboxing", or there could be > something like --no-sandbox (runtime option). But until then, > it could be acceptable to disable sandboxing? IMHO it should fallback automatically. xz is a low level tool that is plumbed into a variety of other tools, and modifying all those tools to add a hypothetical "--no-sandbox" flag is impractical
Just a bit more detail about what's going on here. The xz ./configure script detects if landlock is available here: https://github.com/tukaani-project/xz/blob/8d26b72915e0d373f898b55935505857c30dbdb3/configure.ac#L1238 In the Koji output we detect and enable it based on the capabilities of the Koji server: checking for cap_rights_limit... no checking for pledge... no checking if Linux Landlock is usable... yes Hence based on that build time test, HAVE_LINUX_LANDLOCK is defined. That causes the following code to get compiled in: https://github.com/tukaani-project/xz/blob/8d26b72915e0d373f898b55935505857c30dbdb3/src/xz/sandbox.c#L112 It is currently enabled unconditionally (ie. the --no-sandbox flag is hypothetical). As Dan says already, we do need a solution that will work in containers etc without needing everyone to add hypothetical options everywhere, if that was even possible which it isn't because the xz caller doesn't know what the kernel supports. Can we just add a runtime check to prctl and continue without the sandbox if the kernel call fails? That seems like it wouldn't compromise security. https://github.com/tukaani-project/xz/blob/8d26b72915e0d373f898b55935505857c30dbdb3/src/xz/sandbox.c#L175
Filed upstream bug: https://github.com/tukaani-project/xz/issues/199
Current thinking is this may be a RHEL 9 kernel bug. I filed: https://issues.redhat.com/browse/RHEL-125143
This is affecting my internal koji-kiwi builds on CentOS Stream 9. We build internal Fedora liveinstall images with our internal tools to standardize our desktop experience.
For memory, this also affects using mock on RHEL-9.7 (Fedora >= 41 targets) + /usr/lib/rpm/rpmuncompress -x /builddir/build/SOURCES/php-8.5.0.tar.xz /usr/bin/xz: Failed to enable the sandbox /usr/bin/tar: This does not look like a tar archive /usr/bin/tar: Exiting with failure status due to previous errors RPM build errors:
I added this workaround to xz in Fedora Rawhide. If this fixes the problem then I suggest we go with this instead of disabling the sandbox. Of course the real fix still has to be done in the RHEL 9 kernel. https://koji.fedoraproject.org/koji/taskinfo?taskID=139175354
I believe this should fix any issues with xz on top of RHEL 9 kernels. Please test! https://koji.fedoraproject.org/koji/buildinfo?buildID=2864840
I run a set of scratch builds, using rawhide sources (cannot run it locally as my builder is running RHEL-9.7, chicken/eggs issue) F41: https://koji.fedoraproject.org/koji/taskinfo?taskID=139276020 F42: https://koji.fedoraproject.org/koji/taskinfo?taskID=139276019 F43: https://koji.fedoraproject.org/koji/taskinfo?taskID=139276015 Adding these packages to my Fedora buildroot, everything now runs correctly, running mock on RHEL-9.7 with Fedora targets: + /usr/lib/rpm/rpmuncompress -x /builddir/build/SOURCES/php-8.4.12.tar.xz + STATUS=0 Please push to the other fedora stable branches
If we think this is a good idea, I can do it this afternoon. I did want to wait just a little to make sure there was no regression in Rawhide ...
Thinking about this, since we have bodhi gating, there's no problem with adding these to the earlier branches straightaway.
FEDORA-2025-33f3c8843c (xz-5.8.1-4.fc42) has been submitted as an update to Fedora 42. https://bodhi.fedoraproject.org/updates/FEDORA-2025-33f3c8843c
FEDORA-2025-8b280bf07f (xz-5.8.1-4.fc43) has been submitted as an update to Fedora 43. https://bodhi.fedoraproject.org/updates/FEDORA-2025-8b280bf07f
FEDORA-2025-7cf4096b4a (xz-5.8.1-4.fc41) has been submitted as an update to Fedora 41. https://bodhi.fedoraproject.org/updates/FEDORA-2025-7cf4096b4a
FEDORA-2025-8b280bf07f has been pushed to the Fedora 43 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2025-8b280bf07f` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2025-8b280bf07f See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2025-33f3c8843c has been pushed to the Fedora 42 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2025-33f3c8843c` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2025-33f3c8843c See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2025-7cf4096b4a has been pushed to the Fedora 41 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2025-7cf4096b4a` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2025-7cf4096b4a See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2025-8b280bf07f (xz-5.8.1-4.fc43) has been pushed to the Fedora 43 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2025-33f3c8843c (xz-5.8.1-4.fc42) has been pushed to the Fedora 42 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2025-7cf4096b4a (xz-5.8.1-4.fc41) has been pushed to the Fedora 41 stable repository. If problem still persists, please make note of it in this bug report.