Description of problem: when running fixfiles -v -F relabel files in /var/named/chroot are incorrectly relabeled because of loop in /var/named/chroot/var/named/chroot. Policy should be configured to ignore /var/named/chroot/var/named/chroot directory. Version-Release number of selected component (if applicable): selinux-policy-targeted-3.13.1-283.17.fc27.noarch How reproducible: Steps to Reproduce: 1. Run fixfiles -v -F relabel 2. reboot 3. avc denied in logs Actual results: Files are incorrectly relabeled. Expected results: Files should not be relabeled. Additional info:
Or should this be bug of fixfiles?
This is the workaround: # fixfiles -v -F relabel # cd /var/named/chroot # restorecon -R -v . Restorecon will fix the wrongly relabeled files.
I think named-chroot or named-sdb-chroot service has to be running. Otherwise there would not be /var/named/chroot/var/named/chroot.
Yes, sure. I have named-chroot running.
Something wrong with that?
There is little I can do about loop I think. bind-chroot package, resp. /usr/libexec/setup-named-chroot.sh script, mount --bind --make-private /var/named to /var/named/chroot/var/named. It has to do it to include all zones in /var/named to chroot. Loop has to be solved somehow in selinux relabel tools. Is there way to mark all files in /var/named/chroot/var/named the same way as /var/named? I am not sure how can I end such loop.
How about setting the /var/named/chroot tree out of labelling? Or should the bug be moved to the tools package?
Hi, Could you try this command and then re-run restorecon? # semanage fcontext -a -e /var/named /var/named/chroot/var/named Thanks, Lukas.
Hi, first, the restorecon worked correctly before. But I had problem with fixfiles. But after command you recommended the fixfiles is working ok now. Thanks for recommendation. Will this be part of the next version of policy? Marek
Marek, Is path "/var/named/chroot/var/named" part of default configuration for bind? Thanks, Lukas.
Hi Lukas, the /var/named/chroot structure is bind mounted when starting default fedora named-chroot service instead of named. It is done by /usr/libexec/setup-named-chroot.sh script. Marek
Yep, make sense. Adding fixes to Fedora: https://src.fedoraproject.org/rpms/selinux-policy/c/9fb60ef78aac7fed403cf29f49fa37e6a53841f5?branch=master
Hi, it is strange # semanage fcontext -a -e /var/named /var/named/chroot/var/named helped. Because I was observing also mislabeling in /var/named/chroot/dev directory. And potentially others in /var/named/chroot structure. Marek
FEDORA-2019-f83217e2bf has been submitted as an update to Fedora 30. https://bodhi.fedoraproject.org/updates/FEDORA-2019-f83217e2bf
Great. I should probably remove the line: # semanage fcontext -d -e /var/named /var/named/chroot/var/named prior to installing update. Am I right? Thanks Marek
selinux-policy-3.14.3-51.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-f83217e2bf
Yes, you could remove it, but it's not necessary. Lukas.
FEDORA-2019-70d80ad4bc has been submitted as an update to Fedora 30. https://bodhi.fedoraproject.org/updates/FEDORA-2019-70d80ad4bc
selinux-policy-3.14.3-52.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-70d80ad4bc
Unfortunately, in the meantime I upgraded to Fedora 31. I am no longer able to test F30 packages. The problem is present in Fedora 31.
Hi Marek, What is output of: # rpm -q selinux-policy THanks, Lukas.
selinux-policy-3.14.4-39.fc31.noarch
In selinux-policy-3.14.4-40.fc31.noarch still not working.
selinux-policy-3.14.3-52.fc30 has been pushed to the Fedora 30 stable repository. If problems still persist, please make note of it in this bug report.