[Error] Fedora distrobox can't access /dev/null ?

[sfalken]

Describe the bug
Rootful Fedora 43 Distrobox, fedpkg mockbuild is failing, I suspect due to /dev/null being inaccessible?

To Reproduce

1. Create Rootful F43 Distrobox, via distrobox create --root -i quay.io/fedora/fedora:43 -n fpkg --init -additional-packages 'systemd fedora-packager'
2. Grab fedora sources via fedpkg co niri-settings (just using niri-settings as an example, this is happening with all attempted mockbuilds, regardless of package)
3. Run fedpkg mockbuild on sources
4. mockbuild process fails, during setup of the mock buildroot, suspected due to:

>>> Running %triggerin scriptlet: info-0:7.2-7.fc44.x86_64
>>> Non-critical error in %triggerin scriptlet: info-0:7.2-7.fc44.x86_64
>>> Scriptlet output:
>>> /var/tmp/rpm-tmp.J2jliB: line 2: /dev/null: Permission denied
>>> 
>>> [RPM] %transfiletriggerin(info-7.2-7.fc44.x86_64) scriptlet failed, exit status 1
>>> Running %triggerpostun scriptlet: info-0:7.2-7.fc44.x86_64
>>> Non-critical error in %triggerpostun scriptlet: info-0:7.2-7.fc44.x86_64
>>> [RPM] %transfiletriggerpostun(info-7.2-7.fc44.x86_64) scriptlet failed, exit status 1

Expected behavior
fedpkg mockbuild runs and sets up the buildroot properly and creates a local rpm

Logs
Run the commands with --verbose and post the log here as a file upload

distrobox-fpkg-verbose.txt

podman-logs.txt

Desktop (please complete the following information):

• Podman 5.7.1
• distrobox version: 1.8.2.2
• Kalpa Desktop (openSUSE Tumbleweed/MicroOS)
• Distribution provided RPM packages

Additional context

mockbuild.txt Log of the actual mockbuild

Apparently, in Fedora 42, rpmbuild was allowed to ignore these "Non-Critical Errors" in mockbuild, and proceed normally. In F43 and Rawhide, that policy has now changed.

I don't actually know what the issue is. Or if access to /dev/null has anything to do with it, but those errors were there with F42, and I could build fine. This may, or may not be a distrobox issue with permissions, but so far, I can't seem to narrow down where the actual problem is.

[Conan-Kudo]

It is likely that devfs access is not quite right in distrobox/podman/etc., but the actual change is that any nonzero error code (as opposed to just error code 1) will fail the RPM transaction. This was done in RPM 6.0, so scriptlets need to be hardened against even more failure cases.