Description of problem: If you use networkd, /etc/resolv.conf is a link to /run/systemd/resolve/resolv.conf. Postfix by default, uses it's own resolver (configuration settings [ls]mtp_host_lookup). But SElinux prevents postfix from reading the file: type=AVC msg=audit(1500233894.619:290): avc: denied { read } for pid=2658 comm="smtp" name="resolv.conf" dev="tmpfs" ino=30351 scontext=system_u:system_r:postfix_smtp_t:s0 tcontext=system_u:object_r:systemd_resolved_var_run_t:s0 tclass=file permissive=0 or type=AVC msg=audit(1500234143.604:335): avc: denied { getattr } for pid=792 comm="nscd" path="/run/systemd/resolve/resolv.conf" dev="tmpfs" ino=30351 scontext=system_u:system_r:nscd_t:s0 tcontext=system_u:object_r:systemd_resolved_var_run_t:s0 tclass=file permissive=0 As such, postfix reports an error like that: dsn=4.4.3, status=deferred (Host or domain name not found. Name service error for name=some.fqdn.com type=AAAA: Host not found, try again) Which isn't really clear... Version-Release number of selected component (if applicable): Fedora 26, package 3.13.1-259 How reproducible: Setup a relay in postfix (configuration setting relayhost) and try to send an email. I guess it's somewhat similiar to BZ#1075193. Let me know if you need anything else.
Mathieu, Label of /run/systemd/resolve/resolv.conf shoudl be net_conf_t. On your system label of /run/systemd/resolve/resolv.conf is systemd_resolved_var_run_t. This is not good. Could you restore labels on /run/systmed/resolve using following command: # restorecon -Rv /run/systemd/ and then try to reproduce the issue? Thanks, Lukas.
Hello Lukas, Yes restorecon changed the label but then I had done a full relabeling on boot before. # restorecon -Rv /run/systemd/ Relabeled /run/systemd/resolve/resolv.conf from system_u:object_r:systemd_resolved_var_run_t:s0 to system_u:object_r:net_conf_t:s0 If I reboot the box in question: %ls -lZ /run/systemd/resolve/resolv.conf -rw-r--r--. 1 systemd-resolve systemd-resolve system_u:object_r:systemd_resolved_var_run_t:s0 549 Jul 20 22:56 /run/systemd/resolve/resolv.conf Not sure what's going on (and sure enough restorecon fixes it again but it doesn't solve the problem). If I do semanage fcontext -l | fgrep /resolve, I do get net_conf_t: /var/run/systemd/resolve(/.*)? all files system_u:object_r:systemd_resolved_var_run_t:s0 /var/run/systemd/resolve/resolv\.conf regular file system_u:object_r:net_conf_t:s0
To make sure it wasn't an old local module messing with that, I even removed selinux-policy and selinux-policy-targeted, then remove /etc/selinux/targeted before reinstalling, relabeling and enabline selinux again. Same result...
I also have this issue which affects a whole host of daemons (all that require access to /etc/resolv.conf)
Same here with chronyd, abrt-action-sav, cupsd, httpd... They all complain that "/run/systemd/resolve/resolv.conf default label should be net_conf_t." /run/systemd/resolve/resolv.conf is maintained by systemd-resolved
selinux-policy-3.13.1-260.4.fc26 has been submitted as an update to Fedora 26. https://bodhi.fedoraproject.org/updates/FEDORA-2017-323fb6bb66
selinux-policy-3.13.1-260.4.fc26 has been pushed to the Fedora 26 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2017-323fb6bb66
selinux-policy-3.13.1-260.4.fc26 has been pushed to the Fedora 26 stable repository. If problems still persist, please make note of it in this bug report.
Problem still persists with selinux-policy-3.13.1-260.4.fc26.noarch In my case, it is php-fpm, which is prevented from reading resolv.conf: AVC avc: denied { read } for pid=1415 comm="php-fpm" name="resolv.conf" dev="tmpfs" ino=85410 scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:object_r:systemd_resolved_var_run_t:s0 tclass=file permissive=0
I also experience this problem - have just today updated from f25. Please reopen as the selinux-policy update did not fix this issue.
selinux-policy-3.13.1-260.8.fc26 has been submitted as an update to Fedora 26. https://bodhi.fedoraproject.org/updates/FEDORA-2017-fd93b6e5f8
selinux-policy-3.13.1-260.8.fc26 has been pushed to the Fedora 26 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2017-fd93b6e5f8
selinux-policy-3.13.1-260.8.fc26 has been pushed to the Fedora 26 stable repository. If problems still persist, please make note of it in this bug report.
still a problem AFAICT
(In reply to Fedora Update System from comment #13) > selinux-policy-3.13.1-260.8.fc26 has been pushed to the Fedora 26 stable > repository. If problems still persist, please make note of it in this bug > report. The above update did not fix the issue of /run/systemd/resolve/resolv.conf getting the wrong label (system_u:object_r:systemd_resolved_var_run_t:s0). After boot, /run/systemd/resolve/resolv.conf is labeled with system_u:object_r:systemd_resolved_var_run_t:s0. Even after restorecon which does properly change the label to system_u:object_r:net_conf_t:s0, when restarting systemd-resolved, /run/systemd/resolve/resolv.conf is (re)labeled with system_u:object_r:systemd_resolved_var_run_t:s0. Please reopen.
see also bug #1486567 which I opened as this bug wasn't reopened...
selinux-policy-3.13.1-260.9.fc26 has been submitted as an update to Fedora 26. https://bodhi.fedoraproject.org/updates/FEDORA-2017-0cf00e6f4e
selinux-policy-3.13.1-260.9.fc26 has been pushed to the Fedora 26 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2017-0cf00e6f4e
selinux-policy-3.13.1-260.9.fc26 has been pushed to the Fedora 26 stable repository. If problems still persist, please make note of it in this bug report.
problem still apears with selinux-policy-3.13.1-260.9.fc26 ls -Z /run/systemd/resolve/resolv.conf system_u:object_r:systemd_resolved_var_run_t:s0 /run/systemd/resolve/resolv.conf ls -Z /var/run/systemd/resolve/resolv.conf system_u:object_r:systemd_resolved_var_run_t:s0 /var/run/systemd/resolve/resolv.conf semanage fcontext -l |grep resolv /etc/\.resolv\.conf.* all files system_u:object_r:net_conf_t:s0 /etc/ppp/resolv\.conf regular file system_u:object_r:pppd_etc_rw_t:s0 /etc/resolv-secure.conf.* all files system_u:object_r:net_conf_t:s0 /etc/resolv\.conf.* all files system_u:object_r:net_conf_t:s0 /etc/sysconfig/network-scripts/.*resolv\.conf regular file system_u:object_r:net_conf_t:s0 /usr/lib/policykit/polkit-resolve-exe-helper.* regular file system_u:object_r:policykit_resolve_exec_t:s0 /usr/lib/systemd/resolv.* regular file system_u:object_r:lib_t:s0 /usr/lib/systemd/system/systemd-resolved\.service all files system_u:object_r:systemd_resolved_unit_file_t:s0 /usr/lib/systemd/systemd-resolve(d|-host) all files system_u:object_r:systemd_resolved_exec_t:s0 /usr/libexec/polkit-resolve-exe-helper.* regular file system_u:object_r:policykit_resolve_exec_t:s0 /var/run/NetworkManager/resolv\.conf.* regular file system_u:object_r:net_conf_t:s0 /var/run/systemd/resolve(/.*)? all files system_u:object_r:systemd_resolved_var_run_t:s0 /var/run/systemd/resolve/resolv.conf all files system_u:object_r:net_conf_t:s0 /var/run/systemd/resolve/resolv\.conf regular file system_u:object_r:net_conf_t:s0
Hi Lukas. This ticket keeps getting closed with each new selinux-policy release for F26, but in reviewing the diff between the changes made upstream and in -contrib, I can't seem to find that any of the changes were even remotely related to this problem. Is there something specific I'm missing in the upstream changes? Or perhaps is this something that needs to go upstream to systemd since even after the files are labeled appropriately, a restart of systemd-resolved reverts the file context to systemd_resolved_var_run_t?
This should be fixed by something like: https://github.com/fedora-selinux/selinux-policy/pull/202 You could try it out by installing the following policy. #======================== cut ============================================= policy_module(mysystemd, 1.0) gen_require(` type systemd_resolved_t, systemd_resolved_var_run_t; ') sysnet_filetrans_config_fromdir(systemd_resolved_t,systemd_resolved_var_run_t, file, "resolv.conf") sysnet_filetrans_config_fromdir(systemd_resolved_t,systemd_resolved_var_run_t, file, "resolv.conf.tmp") #======================================================================== make -f /usr/share/selinux/devel/Makefile semodule -i mysystemd
selinux-policy-3.13.1-260.10.fc26 has been submitted as an update to Fedora 26. https://bodhi.fedoraproject.org/updates/FEDORA-2017-29d4eac4a8
selinux-policy-3.13.1-260.10.fc26 has been pushed to the Fedora 26 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2017-29d4eac4a8
selinux-policy-3.13.1-260.10.fc26 has been pushed to the Fedora 26 stable repository. If problems still persist, please make note of it in this bug report.
(In reply to Fedora Update System from comment #25) > selinux-policy-3.13.1-260.10.fc26 has been pushed to the Fedora 26 stable > repository. If problems still persist, please make note of it in this bug > report. Unfortunately, this was not fixed with selinux-policy-3.13.1-260.10.fc26.
Could someone with the right permissions reopen this bug, please?
selinux-policy-3.13.1-260.12.fc26 has been submitted as an update to Fedora 26. https://bodhi.fedoraproject.org/updates/FEDORA-2017-88b6a06bce
selinux-policy-3.13.1-260.12.fc26 has been pushed to the Fedora 26 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2017-88b6a06bce
selinux-policy-3.13.1-260.13.fc26 has been submitted as an update to Fedora 26. https://bodhi.fedoraproject.org/updates/FEDORA-2017-88b6a06bce
selinux-policy-3.13.1-260.13.fc26 has been pushed to the Fedora 26 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2017-88b6a06bce
selinux-policy-3.13.1-260.13.fc26 has been pushed to the Fedora 26 stable repository. If problems still persist, please make note of it in this bug report.
Problem still persists with 3.13.1-260.13.fc26 : read access denied on /run/systemd/resolve/resolv.conf for chronyd, cupsd, httpd
still an issue. solvable (until next boot) with [bangert@stuart ~]$ sudo restorecon -Rv /run/systemd/ [sudo] password for bangert: Relabeled /run/systemd/resolve/resolv.conf from system_u:object_r:systemd_resolved_var_run_t:s0 to system_u:object_r:net_conf_t:s0
steps to reproduce : fresh install upgrade systemctl disable NetworkManager.service systemctl enable systemd-networkd.service systemd-resolved.service reboot ln -s /run/systemd/resolve/resolv.conf /etc/resolv.conf
This issue still occurs with F27. Please reopen.
What is going on? Hasn't systemd-networkd been supported for a long time? I don't understand how this is still an issue.
Problem is still present...
Guys, Are you still have this issue with the latest selinux-policy builds? Thanks, Lukas.
As the system is not usable in the broken configuration (i.e. systemd-resolved in second mode where /etc/resolv.conf is a symlink), I would have to change my system configuration to tell, for sure right now. If you can wait, I'll try it later. However, since /run/systemd/resolve/resolv.conf still has the wrong label, I doubt it is fixed. There is a note in selinux-policy changelog that says this specifically was corrected, but it doesn't seem like it worked. $ sudo -i restorecon -v /run/systemd/resolve/resolv.conf Relabeled /run/systemd/resolve/resolv.conf from system_u:object_r:systemd_resolved_var_run_t:s0 to system_u:object_r:net_conf_t:s0
This continues to be an issue in F27 builds. I think in another ticket you indicated the issue was resolved in a rawhide VM, so I've been waiting a bit. However in F27, the issue is persistent despite the file context labels in /etc/selinux/targeted/contexts/files being correct. Is there some upstream issue here when systemd itself is relabeling the file--it happens after each restart of systemd-networkd or if a new dhcp lease is obtained.
Michal, Systemd-resolved is renaming stub-resolv.conf to resolv.conf in /run/systemd/resolve/resolv.conf ? For some reason we have resolv.conf labeled as systemd_resolved_var_run_t instead of net_conf_t but I see stub-resolv.conf in "resolve" directory. This renaming can cause this issue. I added fixes that systemd_resolved_t can create stub-resolv.conf as net_conf_t label. Please let me know if my assumptions are right. Thanks, Lukas.
(In reply to Lukas Vrabec from comment #42) > Michal, > > Systemd-resolved is renaming stub-resolv.conf to resolv.conf in > /run/systemd/resolve/resolv.conf ? No, these are two distinct files. /run/systemd/resolve/resolv.conf contains list of uplink DNS servers (provided by DHCP server usually) while /run/systemd/resolve/stub-resolv.conf containst only one nameserver entry pointing to local stub resolver on 127.0.0.53. > For some reason we have resolv.conf labeled as systemd_resolved_var_run_t > instead of net_conf_t but I see stub-resolv.conf in "resolve" directory. > This renaming can cause this issue. systemd-resolved takes care of labeling by looking up paths in selinux-policy before it creates temp files. IOW, temp files have labels according to policy. [root@localhost ~]# ls -lZ /run/systemd/resolve/.#resolv.confp3sG7G -rw-r--r--. 1 systemd-resolve systemd-resolve system_u:object_r:net_conf_t:s0 0 Mar 1 18:02 /run/systemd/resolve/.#resolv.confp3sG7G > > I added fixes that systemd_resolved_t can create stub-resolv.conf as > net_conf_t label. > Please let me know if my assumptions are right. That should fix the issue. However, I still see wrong file context in rawhide, [root@localhost ~]# rpm -q selinux-policy selinux-policy-3.14.2-2.fc29.noarch [root@localhost ~]# matchpathcon /run/systemd/resolve/stub-resolv.conf /run/systemd/resolve/stub-resolv.conf system_u:object_r:systemd_resolved_var_run_t:s0
Fixed. Thanks.
selinux-policy-3.13.1-283.28.fc27 has been submitted as an update to Fedora 27. https://bodhi.fedoraproject.org/updates/FEDORA-2018-32ebae3424
I just updated my policy to the one from bodhi and same thing: %uptime 21:11:36 up 8 min, 1 user, load average: 0.63, 1.15, 0.82 %rpm -qa selinux\* selinux-policy-3.13.1-283.28.fc27.noarch selinux-policy-targeted-3.13.1-283.28.fc27.noarch %sudo restorecon -v /run/systemd/resolve/resolv.conf Relabeled /run/systemd/resolve/resolv.conf from system_u:object_r:systemd_resolved_var_run_t:s0 to system_u:object_r:net_conf_t:s0 So I'm afraid the problem is still present
selinux-policy-3.13.1-283.28.fc27 has been pushed to the Fedora 27 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2018-32ebae3424
worked around with: cp /usr/lib/systemd/system/systemd-resolved.service /etc/systemd/system/systemd-resolved.service Changed "ReadWritePaths" parameter with: ReadWritePaths=/run/systemd /var/run/systemd/system in /etc/systemd/system/systemd-resolved.service
(In reply to Zachary Elcor from comment #49) > worked around with: > > cp /usr/lib/systemd/system/systemd-resolved.service > /etc/systemd/system/systemd-resolved.service > > Changed "ReadWritePaths" parameter with: > > ReadWritePaths=/run/systemd /var/run/systemd/system > > in /etc/systemd/system/systemd-resolved.service Zachary when you say "worked around with..." do you mean that the resolv.conf file is labeled correctly as system_u:object_r:net_conf_t:s0 or do you mean that with the file is then readable with SELinux enforcing? In permissive mode, and your workaround applied, I still show resolv.conf labeled with system_u:object_r:systemd_resolved_var_run_t:s0 after a relabel/reboot or after a relabel and restart of systemd-resolved.service. This is with selinux-policy-targeted-3.13.1-283.28.fc27.noarch
(In reply to comment #50) With workaround from comment #49, I now have /run/systemd/resolve/resolv.conf labeled as system_u:object_r:net_conf_t:s0 selinux-policy-targeted-3.13.1-283.26.fc27.noarch with Enforcing mode
selinux-policy-3.13.1-283.28.fc27 has been pushed to the Fedora 27 stable repository. If problems still persist, please make note of it in this bug report.
Reopening because the new selinux policy didn't fix it.
*** This bug has been marked as a duplicate of bug 1556862 ***
bug #1556862 appears to be locked -- access denied.