Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
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.
DescriptionJan Pazdziora (Red Hat)
2022-11-25 10:23:01 UTC
Description of problem:
On fresh RHEL 9.2 nightly installation, restorecon -vv /run/NetworkManager/no-stub-resolv.conf reports
Would relabel /run/NetworkManager/no-stub-resolv.conf from system_u:object_r:NetworkManager_var_run_t:s0 to system_u:object_r:net_conf_t:s0
The file content starts with
# Generated by NetworkManager
Presumably NetworkManager does not label the file properly to match the SELinux policy.
Version-Release number of selected component (if applicable):
NetworkManager-1.41.5-1.el9.x86_64
selinux-policy-38.1.1-1.el9.noarch
How reproducible:
Deterministic.
Steps to Reproduce:
1. Install RHEL.
2. restorecon -nvv /run/NetworkManager/no-stub-resolv.conf
Actual results:
Would relabel /run/NetworkManager/no-stub-resolv.conf from system_u:object_r:NetworkManager_var_run_t:s0 to system_u:object_r:net_conf_t:s0
Expected results:
No such message, the context of the file already matches the SELinux policy.
Additional info:
This is a regression against RHEL 9.1 GA with
NetworkManager-1.40.0-1.el9.x86_64
selinux-policy-34.1.43-1.el9.noarch
The file context (system_u:object_r:NetworkManager_var_run_t:s0) is the same. So it's well possible that the SELinux policy has changed in RHEL 9.2, so either NetworkManager should reflect that, or that SELinux policy change needs to be reverted.
with selinux-policy 38.1.9-1.el9_2:
$ ls -laZ /etc/resolv.conf /run/NetworkManager/{no-stub-,}resolv.conf
-rw-r--r--. 1 root root system_u:object_r:net_conf_t:s0 147 Mar 22 12:00 /etc/resolv.conf
-rw-r--r--. 1 root root system_u:object_r:NetworkManager_var_run_t:s0 147 Mar 22 12:00 /run/NetworkManager/no-stub-resolv.conf
-rw-r--r--. 1 root root system_u:object_r:net_conf_t:s0 147 Mar 22 12:00 /run/NetworkManager/resolv.conf
this is indeed wrong.
Note that NetworkManager will write those files by first creating a file "no-stub.resolv.conf.XXXXXX" (where XXXXXX are random characters) and do an atomic rename. I guess, the policy needs to account for that? That also applies to /etc/resolv.conf, /run/NetworkManager/resolv.conf and most files that NetworkManager writes (that is, not modifying the file in-place but doing the mktemp dance).
I think, "no-stub-resolv.conf" should be treated exactly the same as /run/NetworkManager/resolv.conf, which already seems to get the right labels.
Reassinging to selinux-policy.
Hi, sorry for the incomplete message.
Is there some new change in the NetworkManager? Our SELinux policy for Fedora and RHEL9.2 is the same.
Also in the SELinux policy is not possible to handle random characters.
Fedora 37 shows the same problem.
Thanks to Thomas explanation, it became clear to me that the pattern for the no-stub-resolv.conf
/var/run/NetworkManager/no-stub-resolv\.conf regular file system_u:object_r:net_conf_t:s0
needs to get the ".*" suffix like it is done here:
/var/run/NetworkManager/resolv\.conf.* regular file system_u:object_r:net_conf_t:s0
@thaller can answer if anything changed in NM.
My guess is that the no-stub-resolv.conf is rarely used and therefore next to no one will actually notice that the label is wrong.
> @thaller can answer if anything changed in NM.
I am not aware of any changes in this regard.
What was said in comment 5 sounds right to me (thanks Till!).