Hide Forgot
+++ This bug was initially created as a clone of Bug #1360969 +++ Description of problem: When using the -C option for fixfiles, the verify and check commands (which are supposed to not change any filesystem labels) actually *do* modify labels. Version-Release number of selected component (if applicable): policycoreutils-2.0.83-30.1.el6_8.x86_64 How reproducible: somewhat easily Steps to Reproduce: 1. Make a fake version of /etc/selinux/targeted/contexts/files/file_contexts with rules for /etc removed, so that when you pass it to fixfiles -C it will try to relabel /etc: cp /etc/selinux/targeted/contexts/files/file_contexts file_contexts_dummy sed -i -e '/^\/etc/d' file_contexts_dummy 2. Make a mislabelled file in /etc: touch /etc/relabelthis chcon -t admin_home_t /etc/relabelthis 3. Run: fixfiles -C file_contexts_dummy check or: fixfiles -C file_contexts_dummy verify Actual results: Prints: /sbin/restorecon reset /etc/relabelthis context unconfined_u:object_r:admin_home_t:s0->unconfined_u:object_r:etc_t:s0 and then file context is actually changed: -rw-r--r--. root root unconfined_u:object_r:etc_t:s0 /etc/relabelthis Expected results: Should print but not change file context. Additional info: Seems to be because -n is not being passed down to restorecon properly in the code path for -C. This patch fixes it:
Do you consider this bug to be a high severity issue? Otherwise given that RHEL-6 is already in production phase 2, we won't fix it. It's already fixed in RHEL-7.3.
As long as there is no customer case I think we can close this bug if you consider this issue as unimportant.