Red Hat Bugzilla – Bug 1458831
'/sbin/fixfiles restore' doesn't relabel all files when run from /.autorelabel or from system when some special files are present in /tmp
Last modified: 2018-04-10 12:37:28 EDT
== Description of problem: System doesn't relabel all files on '/' filesystem when using '/.autorelabel' or '/sbin/fixfiles restore' when structures generated by ReaR are present in the /tmp. == Version-Release number of selected component (if applicable): policycoreutils-2.5-11.el7_3 == How reproducible: Always == Steps to Reproduce: 1. Start with clean minimal RHEL 7.3 installation with defaults. 2. Follow procedure to make backup using ReaR in article https://access.redhat.com/solutions/2115051 with one exception - configure variable BACKUP_PROG_EXCLUDE to not contain defaults so the '/tmp' gets included in backup. For example use BACKUP_PROG_EXCLUDE=('/var/crash'). 3. Try restoring the system from the generated backup. == Actual results: System restores from ReaR successfully, boot to relabel all files, reboot and fails to boot because some files were not relabelled correctly. == Expected results: System restores from ReaR successfully, boot to relabel all files, reboot and works normally. == Additional info: Investigating further if the system is is booted with 'enforcing=0' I can see that some files in system according to 'restorecon -vnR /' doesn't have correct label and has 'system_u:object_r:tmp_t:s0' label instead. Files that has wrong label seems to be symlinked from /tmp/rear.*/ directories. '/sbin/fixfiles restore' always exists with exit code 0 which I would expect means that files were relabelled correctly. Running '/sbin/fixfiles restore' doesn't cause the files to get correct label. Running 'restorecon -vR /' restores correct labels in system. I would expect that same would happen when '/.autorelabel' was created and system rebooted.
SELinux does not define labels for most content in /tmp, so fixfiles/restore does not modify the labels. Any content labeled <<none>> will not be relabeled. It is always best to remove all files in /tmp. Or leave them with the label they had when they were moved there.
Hi Dan, I think I haven't explained correctly which files are not getting labelled correctly. I agree that there is no point in concerning about files /tmp. However I'm referring here to files in system like /usr/bin/true or /usr/lib64/libcrypto.so.1.0.0 and many others that will not have a correct label after either running '/sbin/fixfile restore' or making 'touch /.autorelabel; reboot'. Is it expected behaviour that '/sbin/fixfiles restore' doesn't restore label on important system files in /usr/lib64 when some special files in /tmp are present and will exit with exit code '0'? Ondrej
Yes fixfiles should fix the labels and not exit prematurely.
(In reply to Ondrej Faměra from comment #3) > Hi Dan, > > I think I haven't explained correctly which files are not getting labelled > correctly. I agree that there is no point in concerning about files /tmp. > However I'm referring here to files in system like /usr/bin/true or > /usr/lib64/libcrypto.so.1.0.0 and many others that will not have a correct > label after either running '/sbin/fixfile restore' or making 'touch > /.autorelabel; reboot'. > > Is it expected behaviour that '/sbin/fixfiles restore' doesn't restore label > on important system files in /usr/lib64 when some special files in /tmp are > present and will exit with exit code '0'? > > Ondrej Thank you for reporting the issue. I wasn't able to follow the provided reproducer (ReaR restore procedure corrupted my virtual machine's boot loader), could you possibly grant me access to your machine, or better yet provide an example of "special file in /tmp" (file which makes fixfiles crash)?
Turns out that fixfiles doesn't exit prematurely. The "special files" in /tmp contain symbolic links (including links to files in /usr/lib64). Last step of "fixfiles restore" procedure is labeling content of /tmp as tmp_t, which causes reported behaviour (some files in /usr/lib64 are labeled tmp_t because of the symbolic links).
The fix was already approved upstream: https://github.com/SELinuxProject/selinux/commit/2608b4d6660af0fb8ad93f2cc144bdaab3c2afa8
*** Bug 1545664 has been marked as a duplicate of this bug. ***
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHSA-2018:0913