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.
before version 1.2.0, up to rhel-7.2, NetworkManager would rewrite /etc/resolv.conf by first writing to a temporary file /etc/resolv.conf.tmp, which then gets renamed.
Now, NetworkManager uses g_file_set_contents(), which first creates a file like /etc/resolv.conf.LQ18HY, which then gets renamed.
(the pattern here is: "/etc/resolv.conf.XXXXXX")
that fails currently with:
Jun 03 09:56:44 x250 audit[1308]: AVC avc: denied { rename } for pid=1308 comm="NetworkManager" name="resolv.conf.IU9HIY" dev="dm-2" ino=9702046 scontext=system_u:system_r:NetworkManager_t:s0 tcontext=system
_u:object_r:etc_t:s0 tclass=file permissive=1
Is it possible to allow NetworkManager to write to any .XXXXXX file?
Note, that this needs additional caution, because how it was previously,
also resolv.conf.tmp got labeled as unconfined_u:object_r:net_conf_t:s0.
Thus, also the default label for resolv.conf.XXXXXX must be updated.
(In reply to Lukas Vrabec from comment #2)
> Thomas,
> Is this feature also in Fedora?
yes.
Fedora 24+ and rhel-7.3 both have NetworkManager 1.2.0+.
The behavior from comment 1 is necessary with "rc-manager=file" configuration setting. In this case, NM now wants to create temporary file /etc/resolv.conf.XXXXXX (instead of /etc/resolv.conf.tmp).
rc-manager=file will be the default on rhel-7.3, but not on Fedora.
There is another, new mode: rc-manager=symlink.
This is the default on Fedora 24+.
I think, the policy should allow for both ways (rc-manager=file|symlink) on both Fedora and RHEL -- even if the default differs between them.
Another thing... with rc-manager=symlink, NM wants to create a temporary symlink
"/etc/.resolv.conf.NetworkManager" and renames that over to /etc/resolv.conf.
The policy should allow for that too.
Strangely enough, this already works for me on Fedora 23, so I guess there is already a policy change to allow that. Could you please confirm that this is allowed too?
The requested permissions seem to have already been present in the current version as a result of other implemented changes, hence closing CURRENTRELEASE.
before version 1.2.0, up to rhel-7.2, NetworkManager would rewrite /etc/resolv.conf by first writing to a temporary file /etc/resolv.conf.tmp, which then gets renamed. Now, NetworkManager uses g_file_set_contents(), which first creates a file like /etc/resolv.conf.LQ18HY, which then gets renamed. (the pattern here is: "/etc/resolv.conf.XXXXXX") that fails currently with: Jun 03 09:56:44 x250 audit[1308]: AVC avc: denied { rename } for pid=1308 comm="NetworkManager" name="resolv.conf.IU9HIY" dev="dm-2" ino=9702046 scontext=system_u:system_r:NetworkManager_t:s0 tcontext=system _u:object_r:etc_t:s0 tclass=file permissive=1 Is it possible to allow NetworkManager to write to any .XXXXXX file? Note, that this needs additional caution, because how it was previously, also resolv.conf.tmp got labeled as unconfined_u:object_r:net_conf_t:s0. Thus, also the default label for resolv.conf.XXXXXX must be updated.