Bug 867432
Summary: | SELinux prevents NM for unlinking /etc/resolv.conf | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Tomáš Bžatek <tbzatek> |
Component: | anaconda | Assignee: | Anaconda Maintenance Team <anaconda-maint-list> |
Status: | CLOSED WORKSFORME | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | unspecified | Docs Contact: | |
Priority: | unspecified | ||
Version: | 18 | CC: | anaconda-maint-list, danw, dcbw, g.kaviyarasu, jonathan, mgrepl, mkolman, sbueno, tbzatek, tsmetana, vanmeeuwen+fedora |
Target Milestone: | --- | Keywords: | SELinux |
Target Release: | --- | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2013-05-08 00:20:00 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Tomáš Bžatek
2012-10-17 13:51:25 UTC
(crappy sealert browser is preventing me to file it automatically and is eating my comments) Anyway, this is a clean and fully updated F18 install. What I was trying to do was to specify custom DNS for a network connection, ignoring assignment from DHCP. However, /etc/resolv.conf still contained the old information. Manually removing that file make NM successfully writing new configuration. The original file may have been written by instalator and had wrong file contexts. Since NM task is to repair network settings, suggesting to allow unlinking /etc/resolv.conf by NM having any file context. Even though this bugreport is primarily about SELinux policy, there's one thing NM could do: when unlink(2) fails, inform user that the file cannot be deleted and an old configuration will stay active. Not sure where in the stack the call is burried but we need to inform user to expect troubles. I found the /etc/resolv.conf issues by accident, NetwokManager silently succeeded. Ok, /etc/resolv.conf has definitely bad labeling. If you execute # restorecon -R -v /etc/resolv.con does it happen again? We need to find a reason why is mislabeled. The file context is now system_u:object_r:net_conf_t:s0 and been this since I forcefully removed the file and let dhclient recreate it. No idea who has set the wrong initial label, probably a post-installation issue. Too late to find that out now. My bugreport was about allowing unlinking /etc/resolv.conf having any file context from NetworkManager side (or related tools like dhclient or dhcpcd) if possible. Not sure where this bug should belong, but this is a labeling issue. If the file was originally created by Anaconda or any other process during installation, there should be a way how to set the right context - i.e. relabeling. But it seems it hasn't been done post-installation. Alternatively, adding restorecond watch may fix the issue as well. Reassigning to Anaconda for consideration. We run restorecon on this in a post script, it has: system_u:object_r:net_conf_t:s0 on it after a minimal install. |