Hide Forgot
Description of problem: I have a script [1] to build my development toolbox about once a week, which I've used for quite some time now since early Fedora 30. During Fedora 31's alpha and beta periods this also worked reasonably well, but shortly before F31 release it now fails. In particular, it seems that package installs in an F31 now trigger SELinux operations such as restorecon, which break the toolbox in multiple ways. I reduced this quite a bit to get a small reproducer (see below). As soon as selinux-policy{,-targeted} gets installed into the toolbox, things start to go haywire. I don't explicitly want/need this package in my toolbox, but it's an inevitable dependency of e. g. `dnf builddep cockpit`. My understanding is that in containers it should be pretty much inert. [1] https://piware.de/gitweb/?p=bin.git;a=blob;f=build-devtoolbox Version-Release number of selected component (if applicable): selinux-policy-targeted-3.14.4-39.fc31.noarch podman-1.6.2-2.fc31.x86_64 toolbox-0.0.15-1.fc31.noarch kernel-5.3.7-301.fc31.x86_64 How reproducible: Always Steps to Reproduce: 1. toolbox create -c test 2. toolbox run -c test sh -exc 'sudo ln -sfn /run/host/monitor/resolv.conf /etc/resolv.conf; sudo dnf install -y selinux-policy selinux-policy-targeted' 3. toolbox run -c test dnf install -y systemd-udev Actual results: - Step 2 takes a long time as that triggers restorecon¸ which runs at 100% CPU for a minute or two. - Step 3 fails. First, during unpack, there are tons of errors like error: lsetfilecon: (/usr/share/man/man8/kbdrate.8.gz;5dbd4232, system_u:object_r:man_t:s0) Operation not supported and finally Running scriptlet: systemd-udev-243-4.gitef67743.fc31.x86_64 10/14 error: failed to exec scriptlet interpreter /bin/sh: Permission denied error: %prein(systemd-udev-243-4.gitef67743.fc31.x86_64) scriptlet failed, exit status 127 Error in PREIN scriptlet in rpm package systemd-udev Cleanup : systemd-rpm-macros-243-1.fc31.noarch 11/14 error: systemd-udev-243-4.gitef67743.fc31.x86_64: install failed error: systemd-243-1.fc31.x86_64: erase skipped Cleanup : systemd-libs-243-1.fc31.x86_64 12/14 Cleanup : systemd-pam-243-1.fc31.x86_64 13/14 Running scriptlet: systemd-pam-243-1.fc31.x86_64 13/14 error: failed to exec scriptlet interpreter /bin/sh: Permission denied warning: %triggerin(glibc-common-2.30-1.fc31.x86_64) scriptlet failed, exit status 127 Failed: systemd-udev-243-4.gitef67743.fc31.x86_64 systemd-243-4.gitef67743.fc31.x86_64 systemd-243-1.fc31.x86_64 Expected results: Package install works, as before. Additional info: I tried this with `toolbox create --release 30 -c test` and it fails the same way -- i. e. I'm pretty sure that this is a bug on the host side, not the guest. This is *not* a direct regression from cgroupsv2 -- after the initial hiccups with that switch, my script worked fine for a while. This must be related to some of the additional magic in toolbox. Doing this with podman directly works fine: podman run -it --rm -u root fedora:31 bash -exc 'dnf install -y selinux-policy selinux-policy-targeted; dnf install -y systemd-udev' I. e. there is no hang on installing selinux-policy (restorecon isn't being called), no lsetfilecon errors, and package install works fine.
> 2. toolbox run -c test sh -exc 'sudo ln -sfn /run/host/monitor/resolv.conf /etc/resolv.conf; sudo dnf install -y selinux-policy selinux-policy-targeted' Sorry, here my local workaround for "toolbox does not work with systemd-resolved on the host" slipped in. If you use the standard "static /etc/resolv.conf" setup, then it's of course just toolbox run -c test sudo dnf install -y selinux-policy selinux-policy-targeted
CC'ing Andreas and Garrett, two colleagues of mine who also use OSTree and toolbox. FYI, you likely run into the same trouble. I tried to work around this with a simple sudo ln -sfn /dev/null /etc/selinux/config This actually goes get preserved after `dnf install selinux-policy`, but doesn't help to prevent the bug. But removing all files in selinux-policy does, so I added that as a blunt hack to my build script: https://piware.de/gitweb/?p=bin.git;a=commitdiff;h=7e476e5f7c7f4fe
Thanks for the detailed report, Martin! I can reproduce that installing selinux-policy-targeted does take a while inside a toolbox container, but doesn't inside a throwaway 'podman run ...' session. I also got these: Running scriptlet: selinux-policy-targeted-3.14.4-40.fc31.noarch 9/15 SELinux: Could not load policy file /etc/selinux/targeted/policy/policy.31: Permission denied load_policy: Can't load policy: Permission denied
This is the 'restorecon' invocation that's getting "stuck": restorecon -R /root /var/log /run /etc/passwd /etc/passwd- /etc/group /etc/group- /etc/gshadow /etc/gshadow- /etc/shadow /etc/shadow- When run inside a 'podman run ...' session, it cleanly and immediately exits, but when run inside a toolbox container it doesn't and complains a lot about things inside the container's /run/host. For example: /sbin/restorecon: Could not set context for /run/host/usr/share/icons/HighContrast/48x48/actions/view-more.png: Operation not permitted These directories under /run/host that it complains about are bind mounts from the host. /run/host/usr is the host's /usr.
Quickly grepping through the code of restorecon [1], particularly init_selinuxmnt, I see one difference. /sys/fs/selinux is empty inside the 'podman run ...' session, but not inside a toolbox container. I wonder why. [1] https://github.com/SELinuxProject/selinux
https://github.com/containers/toolbox/issues/47 has raised its head again. Compare these two: $ podman run --interactive --tty --network host --privileged --rm registry.fedoraproject.org/f31/fedora-toolbox:31 ls /sys/fs/selinux ... $ podman run --interactive --tty --rm registry.fedoraproject.org/f31/fedora-toolbox:31 ls /sys/fs/selinux
Filed: https://github.com/containers/libpod/issues/4452
FEDORA-2019-78653c0d0b has been submitted as an update to Fedora 31. https://bodhi.fedoraproject.org/updates/FEDORA-2019-78653c0d0b
FEDORA-2019-70b5213b27 has been submitted as an update to Fedora 30. https://bodhi.fedoraproject.org/updates/FEDORA-2019-70b5213b27
FEDORA-2019-c786a43afe has been submitted as an update to Fedora 29. https://bodhi.fedoraproject.org/updates/FEDORA-2019-c786a43afe
toolbox-0.0.17-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-78653c0d0b
toolbox-0.0.17-1.fc30 has been pushed to the Fedora 30 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-70b5213b27
toolbox-0.0.17-1.fc29 has been pushed to the Fedora 29 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-c786a43afe
toolbox-0.0.17-1.fc31 has been pushed to the Fedora 31 stable repository. If problems still persist, please make note of it in this bug report.
toolbox-0.0.17-1.fc30 has been pushed to the Fedora 30 stable repository. If problems still persist, please make note of it in this bug report.