RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
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
Summary: '/sbin/fixfiles restore' doesn't relabel all files when run from /.autorelabe...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: policycoreutils
Version: 7.3
Hardware: All
OS: Linux
medium
medium
Target Milestone: rc
: ---
Assignee: Vit Mojzis
QA Contact: Dalibor Pospíšil
URL:
Whiteboard:
: 1545664 (view as bug list)
Depends On:
Blocks: 1420851 1469954
TreeView+ depends on / blocked
 
Reported: 2017-06-05 15:03 UTC by Ondrej Faměra
Modified: 2021-06-10 12:24 UTC (History)
14 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2018-04-10 16:36:29 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2018:0913 0 None None None 2018-04-10 16:37:27 UTC

Description Ondrej Faměra 2017-06-05 15:03:42 UTC 
== 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.
Comment 2 Daniel Walsh 2017-06-05 21:03:28 UTC 
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.
Comment 3 Ondrej Faměra 2017-06-06 07:41:26 UTC 
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
Comment 4 Daniel Walsh 2017-06-06 12:42:40 UTC 
Yes fixfiles should fix the labels and not exit prematurely.
Comment 5 Vit Mojzis 2017-06-12 12:39:04 UTC 
(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)?
Comment 7 Vit Mojzis 2017-06-14 08:58:08 UTC 
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).
Comment 8 Vit Mojzis 2017-06-28 07:52:33 UTC 
The fix was already approved upstream:
https://github.com/SELinuxProject/selinux/commit/2608b4d6660af0fb8ad93f2cc144bdaab3c2afa8
Comment 12 Renaud Métrich 2018-02-16 12:25:43 UTC 
*** Bug 1545664 has been marked as a duplicate of this bug. ***
Comment 15 errata-xmlrpc 2018-04-10 16:36:29 UTC 
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
Note You need to log in before you can comment on or make changes to this bug.