Bug 2407105

(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.