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 2021835 - .autorelabel does not work anymore in RHEL8.4 if a file required by systemd is unlabelled (/etc/localtime)
Summary: .autorelabel does not work anymore in RHEL8.4 if a file required by systemd i...
Alias: None
Product: Red Hat Enterprise Linux 8
Classification: Red Hat
Component: selinux-policy
Version: 8.4
Hardware: All
OS: Linux
Target Milestone: rc
: 8.6
Assignee: Zdenek Pytela
QA Contact: Milos Malik
Jan Fiala
Depends On:
TreeView+ depends on / blocked
Reported: 2021-11-10 09:44 UTC by Welterlen Benoit
Modified: 2022-05-10 16:24 UTC (History)
12 users (show)

Fixed In Version: selinux-policy-3.14.3-86.el8
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2022-05-10 15:15:37 UTC
Type: Bug
Target Upstream Version:
jafiala: needinfo+

Attachments (Terms of Use)

System ID Private Priority Status Summary Last Updated
Red Hat Bugzilla 2019905 1 unspecified CLOSED If selinux labels are not restored, the autorelabel is not enough in RHEL8.4 and recovered system does not boot 2024-01-20 04:27:21 UTC
Red Hat Issue Tracker RHELPLAN-102378 0 None None None 2021-11-10 16:39:28 UTC
Red Hat Product Errata RHBA-2022:1995 0 None None None 2022-05-10 15:16:04 UTC

Internal Links: 2019905

Description Welterlen Benoit 2021-11-10 09:44:24 UTC
Description of problem:
When a file required by systemd is unlabelled, the autorelabel service can't start because system will die earlier because systemd is not able to access unlabelled files anymore

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. boot with selinux=0
2. change the timezone: timedatectl set-timezone Europe/Rome
3. reboot

Actual results:
- The system can't reboot with "failed to create timezone change event source permission denied"
- and .autorelabel does not work ! because systemd can't access /etc/localtime

Expected results:
- autorelabel should fix the issue

Additional info:
- This has been seen with Rear and a rescue system where label of links are not restored: https://bugzilla.redhat.com/show_bug.cgi?id=2019905

Comment 1 Petr Lautrbach 2021-11-11 09:46:47 UTC
I'm afraid it's not possible to "fix" this in policycoreutils. autorelabel is run by systemd quite early but systemd loads selinux policy at very beginning of the boot process and when the policy is loaded, system is enforcing and filesystem is mislabeled, there's no way back. The only fix is to boot in permissive mode.

But if Rear uses the filesystem in disabled mode and knows that it will be used with SELinux enable, it should relabel (changed) files on its own, e.g. using setfiles command:
  # setfiles -c /chroot/etc/selinux/target/policy/policy.32 -r /chroot/ /chroot/etc/selinux/targeted/contexts/files/file_contexts /chroot

Comment 2 Welterlen Benoit 2021-11-16 10:30:56 UTC

The issue is seen with rear because it is one cause of a wrong label, but as said, simply modifying the timezone with selinux disable will make .autorelabel ineffective.
The relabel should happen very early or a transient state should allow systemd/the autorelabel to work in any condition.
autorelabel is expected to work.

Thank you !


Comment 4 Petr Lautrbach 2021-11-16 11:20:26 UTC
"simply modifying the timezone with selinux disabled" means that there's unlabeled file which is important for systemd and apparently systemd can't work without this file. Timezone initialization happens after the policy is loaded and before any service can be run. There's no way for policycoreutils to workaround or fix it unless it's implemented directly in systemd.

Comment 5 Welterlen Benoit 2021-11-16 11:30:16 UTC

If the autorelabel relies on systemd, it must ensure that systemd can effectively execute what is required to relabel the FS.
From RHEL8.4, the policy does not allow systemd to access unlabelled files anymore. It can be /etc/localtime or any other that will make systemd to fail.

=> autorelabel must be executed before any issue might happen
=> if it relies on systemd, a transient 'permissive' state should allow systemd to execute what is needed and selinux should be enabled "for real" once the FS is correctly labelled
=> or autorelabel must rely on something else


Comment 6 Petr Lautrbach 2021-11-16 11:31:38 UTC
It looks like we're missing some documentation for enabling SELinux. There's an old article which is still valid:


Procedure 5.2. Changing to Enforcing Mode

Before SELinux is enabled, each file on the file system must be labeled with an SELinux context. Before this happens, confined domains may be denied access, preventing your system from booting correctly. To prevent this, configure SELINUX=permissive in /etc/selinux/config

So if you need to reliably relabel system and  prevent access denials for systemd on unlabeled files, you need to boot in permissive mode. Or you can relabel the filesystem before reboot using `setfiles` command as described in #c1.

Comment 7 Welterlen Benoit 2021-11-16 11:40:54 UTC

Thanks, will try the setfiles command.

For rear, I think it's far better to have a way inside the process instead of doing an additional reboot.


Comment 11 Zdenek Pytela 2021-12-01 13:34:22 UTC
Switching to selinux-policy for further troubleshooting based on systemd and selinux teams agreement.

Comment 13 Zdenek Pytela 2021-12-01 14:34:10 UTC
Reproduced, the AVC is reported for the lnk_file class, permission read.

We can resolve this particular issue in selinux-policy, but for other cases it is important to follow the two-step procedure to switch from SELinux disabled to permissive. The documentation is expected be updated.

This is probably the first case when it was a symlink which was created in SELinux disabled mode instead of a plain file, and at the same time it was a file which is critical for systemd to continue to reach the selinux-autorelabel.target.

Comment 18 Zdenek Pytela 2021-12-07 16:39:45 UTC
I've submitted a Fedora PR to address the issue:

Comment 19 Zdenek Pytela 2021-12-10 16:11:08 UTC
To backport:
commit 07b06a7f6cb1f41b92de5d29d21ac89c4d362457 (HEAD -> rawhide, upstream/rawhide, origin/rawhide, origin/HEAD)
Author: Zdenek Pytela <zpytela>
Date:   Tue Dec 7 17:15:44 2021 +0100

    Allow systemd read unlabeled symbolic links

Comment 31 errata-xmlrpc 2022-05-10 15:15:37 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 (selinux-policy bug fix and enhancement update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.


Note You need to log in before you can comment on or make changes to this bug.