Red Hat Bugzilla – Bug 244167
SELinux set to Enforcing prevents /etc/resolv.conf being written on start-up
Last modified: 2007-11-30 17:12:07 EST
Description of problem: DNS lookups stopped working. I tracked it down to an empty /etc/resolv.conf. I guessed it was an issue with SELinux and used the big hammer and disabled it (OK, in retrospect, that wasn't such a great idea, and Permissive would have been a better first step). After rebooting, /etc/resolv.conf was filled in properly by dhclient-script and DNS lookups worked again. Version-Release number of selected component (if applicable): selinux-policy - 2.4.6-74.fc6.noarch - SELinux policy configuration How reproducible: Very, until I turned off SELinux. Steps to Reproduce: Not really sure, but I suspect that it was the last set of updates I installed earlier this week that caused the issue. Evidence is that I'd installed a set of updates a couple of weeks ago that required a reboot, and internet access was working fine then. After the last reboot, I'd had no more update notifications (which I considered a little strange), then the first time I directly tried internet access, it couldn't find the server. Or any server. Actual results: Expected results: Additional info:
Does restorecon /etc/resolv.conf Fix your problem? Somehow it must have gotten mislabeled. You can use restorecond to make sure the context stays correct.
I'll set SELinux back to Enforcing and try it, but I expect that just setting it to Enforcing will relabel the entire file system anyway. This might not be related, as I have two machines with the same log messages, but there are a few messages like this in the log file going back before I noticed this issue: Jun 13 19:33:54 narbalek restorecond: Will not restore a file with more than one hard link (/etc/resolv.conf) Invalid argument I'll update this after re-enabling SELinux. thanks - David
Changing SELinux to Enforcing relabelled the file system, but didn't fix the problem. /etc/resolv.conf was blank after boot. /etc/resolv.conf/predhclient contained the expected entries. /sbin/restorecon -v /etc/resolv.conf showed no changes being made. When I had the problem before, and now after re-enabling SELinux, I get 7 log messages like this one every 15 seconds: Jun 15 09:13:10 narbalek kernel: audit(1181862790.877:233): avc: denied { node_bind } for pid=1891 comm="nscd" scontext=system_u:system_r:nscd_t:s0 tcontext=system_u:object_r:inaddr_any_node_t:s0 tclass=udp_socket Does that have anything to do with it? I have another near-identical but working system that is NOT getting those errors. regards - David
What file is hard linked to resolv.conf? This might be causing your problem. ls -lZ /etc/resolv.conf I have never seen nscd try to bind to that node before, but might be related.
It's linked to /etc/sysconfig/networking/profiles/default/resolv.conf Same on my other machine. I've just checked and it's getting the same messages in the log file, so I don't think that's the issue. Ran the command above: [root@narbalek david]# ls -lZ /etc/resolv.conf -rw-r--r-- root root system_u:object_r:net_conf_t /etc/resolv.conf I also found similar audit errors on the other machine, but there is one error about every hour from 8:30am yesterday to 1:30pm, then none after that, plus two groups of two 30 seconds apart at 9:38am. Interestingly, that'a about when I was composing Comment #3.
And you are seeing no avc messages about net_conf_t or resolv.conf in /var/log/audit/audit.log or /var/log/messages?
Created attachment 157604 [details] Messages about resolv.conf in /var/log/messages*
1. I have no /var/log/audit directory. 2. There are no messages at all in /var/log/messages* about net_conf_t. 3. All the messages in /var/log/messages* about resolv.conf are in the attachment varlogmessages.txt. thanks - David
Does dmesg show anything? This is strange. If you boot in permissive mode "enfocing=0" Does the file get created with the correct context?
Booted again in Enforcing, and the problem was the same: /etc/resolv.conf was blank. Note that /etc/resolv.conf.predhclient was created correctly, so it seems to be an error occurring when /sbin/dhclient-script updates /etc/resolv.conf. I've attached the output of dmesg in Enforcing as bootmessages_enforcing.txt. Booted again in Permissive, and the problem goes away. /etc/resolv.conf is correct, and DNS access works. Ran this again, same results as before with Enforcing on. [root@narbalek regression]# ls -lZ /etc/resolv.conf -rw-r--r-- root root system_u:object_r:net_conf_t /etc/resolv.conf I've attached the output of dmesg in Permissive as bootmessages_permissive.txt. regards - David
Created attachment 158284 [details] Output of dmesg in SELinux Enforcing mode
Created attachment 158285 [details] Output of dmesg in SELinux Permissive mode
Was the dmesg output I sent a couple of months ago of no help with this bug?
Sorry you dropped between the cracks. This looks like you have a tmp directory labeled public_content_rw_t This is most likely wrong audit2allow -i /tmp/t | grep public_content_rw_t allow automount_t public_content_rw_t:dir mounton; allow dhcpc_t public_content_rw_t:dir getattr; allow mysqld_t public_content_rw_t:dir { read search }; allow ntpd_t public_content_rw_t:dir search; allow rhgb_t public_content_rw_t:dir search; allow xfs_t public_content_rw_t:dir search; Did you relabel /tmp or something public_content_rw_t? This could be causing problems. ntpd should be allowed to read samba files in latest release, which I have never seen before nscd trying to read samba files is not something I have seen before.
How do I relabel /tmp? It's certainly labelled public_content_rw_t on the machine that has the problem, and tmp_t on the machine that's OK. But I don't really know how that happened. I've just tried /sbin/restorecon -nv /tmp and it produced no output, also /sbin/fixfiles check /tmp and it also produced no output. I've also ferreted around through the selinux and associated man pages and drawn a blank on changing /tmp to tmp_t. If you can let me know, I'd appreciate it. Note: I have completely relabelled the file system a couple of times, so I would have expected that would have fixed /tmp. Apparently not? Note also that both machines seem to have identical SELinux configurations from paging through the GUI tool at menu System>Administration>Security Level and Firewall, SELinux, Modify SELinux Policy. regards - David
matchpathcon /tmp /tmp system_u:object_r:tmp_t:s0 restorecon /tmp Should fix it. /tmp is a directory? chcon -t tmp_t /tmp Will also fix the context.
restorecon doesn't seem to work. Tried as user, also tried su. [david@narbalek ~]$ restorecon -vv /tmp restorecon: /tmp not reset customized by admin to system_u:object_r:public_content_rw_t:s0 [david@narbalek ~]$ su -c 'restorecon -vv /tmp' Password: restorecon: /tmp not reset customized by admin to system_u:object_r:public_content_rw_t:s0 chcon did work. [david@narbalek ~]$ su -c 'chcon -t tmp_t /tmp' Password: [david@narbalek ~]$ matchpathcon -V /tmp /tmp verified. Also, it looks like I had to do it recursively for /tmp, so I used su -c 'chcon -t tmp_t -R -v /tmp' Now I'll try changing back to Enforcing, restart, and confirm it fixes the original issue with /etc/resolv.conf.
It's all fixed. So it seems that I've unknowingly run chcon in the past, or knowingly and forgotten about it. I don't think it's the former, and the most likely time I would have done it was when I was getting file sharing to /tmp going. That was many months before this resolv.conf issue arose. I wonder what triggered it? (rhetorical) Thanks Dan for all your assistance. I've now found http://fedoraproject.org/wiki/SELinux, so I'll read up.
restorecon -F should work. You should read danwalsh.livejournal.com From the beginning. I write a blog called SELinux for dummies. I think you will get useful info there. setroubleshoot might have told you to do that. Older versions of setroubleshoot sometimes were incorrect in their fix description.