Fedora Account System
Red Hat Associate
Red Hat Customer
[shaka ~]$ sudo docker run --privileged -v /:/host -ti --rm [root@d8968222c858 /]# dnf install -y selinux-policy-devel ... [root@d8968222c858 /]# getenforce Enforcing [root@d8968222c858 /]# dnf install -y strace Last metadata expiration check: 0:01:05 ago on Tue Sep 19 18:29:41 2017. Dependencies resolved. ... Downloading Packages: (1/2): libunwind-1.2-1.fc26.x86_64.rpm 505 kB/s | 64 kB 00:00 (2/2): strace-4.19-1.fc26.x86_64.rpm 2.0 MB/s | 684 kB 00:00 ----------------------------------------------------------------------------------------------------------------------- Total 752 kB/s | 748 kB 00:00 Running transaction check Transaction check succeeded. Running transaction test Transaction test succeeded. Running transaction Failed to obtain the transaction lock (logged in as: root). The downloaded packages were saved in cache until the next successful transaction. You can remove cached packages by executing 'dnf clean packages'. Error: Could not run transaction. [root@d8968222c858 /]# (Never mind that the error message from dnf is completely inappropriate in this case. Running rpm directly would not have resulted in any appropriate error message -- see https://bugzilla.redhat.com/show_bug.cgi?id=1262424). Additional info: Because we're mounting /host, libselinux is able to find the selinuxfs mount and sees that SELinux is enforcing on the host. But when the plugin tries to load the file contexts from /etc/selinux/$policy_type/contexts/files, it of course fails.
A heuristic here is to check if the mount is at /sys/fs/selinux and disable labeling if not. Or maybe a better approach is an OCI hook that can somehow relay to the plugin that labeling is not necessary?
I'd avoid mounting all of / as a rule btw; I generally even with privileged containers just mount /srv. If I e.g. want to test a patch for my host, I build an RPM or `make install DESTDIR=/srv/tmp/rootfs` or so, then on the host root shell do rpm -Uvh /srv/tmp/test.rpm or rsync -rlv /srv/tmp/rootfs/usr /usr/ etc.
(In reply to Jonathan Lebon from comment #0) > Additional info: > > Because we're mounting /host, libselinux is able to find the selinuxfs mount > and sees that SELinux is enforcing on the host. But when the plugin tries to > load the file contexts from /etc/selinux/$policy_type/contexts/files, it of > course fails. You're bringing in invalid information from the host into a container and rpm is somehow supposed to work around it? Like Colin says, don't do that. On a kind of related note, rpm's selinux support was split out into a plugin so you could easily get rid of it. However this was never really completed on Fedora side, rpm still carries this from June 2014: --- # Drag in SELinux support at least for transition phase %if %{with plugins} Requires: rpm-plugin-selinux%{_isa} = %{version}-%{release} %endif --- The idea was to move the dependency to a suitable SELinux component but nobody ever got around to file that bug I guess (and I was in another job for two years in between).
So actually we might just as well use this bug to move the rpm-plugin-selinux dependency to selinux-policy package (see comment #3, I suppose that's where it belongs) which should solve the problem in a more natural way: if there's no selinux-policy installed then there's no plugin to get upset about it either.
Oh and of course, moving the dependency (if SELinux folks agree) should start with rawhide and once possible fallout is dealt with, look at stable releases.
Panu, Could you try your scenario with following scratch build? https://koji.fedoraproject.org/koji/taskinfo?taskID=22237603 Thanks, Lukas.
Um, so you copied the rpm.spec snippet verbatim: # Drag in SELinux support at least for transition phase %if %{with plugins} Requires: rpm-plugin-selinux%{_isa} = %{version}-%{release} %endif There's no with/without_plugins build-conditional in selinux-policy so it'll do absolutely nothing at all, as you can see from the package too: $ rpm -qp --requires selinux-policy-3.13.1-292.fc28.100.noarch.rpm /bin/awk /bin/sh /bin/sh /bin/sh /usr/bin/sha512sum config(selinux-policy) = 3.13.1-292.fc28.100 policycoreutils >= 2.7-1 rpmlib(CompressedFileNames) <= 3.0.4-1 rpmlib(FileDigests) <= 4.6.0-1 rpmlib(PayloadFilesHavePrefix) <= 4.0-1 rpmlib(PayloadIsXz) <= 5.2-1
Oh and BTW, you cannot use %{_isa} there because selinux-policy is a noarch package. And %{version}-%{release} would refer to selinux-policy's version, and there certainly is no rpm-plugin-selinux versioned 3.13.1. This should be quite enough: Requires: rpm-plugin-selinux
Panu, Fixed, could you try this please: https://koji.fedoraproject.org/koji/taskinfo?taskID=22252807 Lukas.
Well I see the dependency is there now but I dont' have really any "scenario" to test. Either the plugin gets pulled in by some package or not, and I doubt we're going to find out about any unexpected side-effects without actually trying it in rawhide.
Thanks. I'll drop the dependency from rpm tomorrowish (to hopefully avoid stuff falling through cracks :) and then we'll see how it goes.
rpm-plugin-selinux dependency dropped in rpm-4.14.0-3.fc28 (rawhide only)
Thanks Panu.
This message is a reminder that Fedora 26 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 26. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '26'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 26 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 26 changed to end-of-life (EOL) status on 2018-05-29. Fedora 26 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.