Bug 213926
| Summary: | dhcpd startup denied -- accessing rndc.key | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Gene Czarcinski <gczarcinski> | ||||
| Component: | bind | Assignee: | Adam Tkac <atkac> | ||||
| Status: | CLOSED CURRENTRELEASE | QA Contact: | Ben Levenson <benl> | ||||
| Severity: | medium | Docs Contact: | |||||
| Priority: | medium | ||||||
| Version: | 6 | CC: | dwalsh, ovasik | ||||
| Target Milestone: | --- | ||||||
| Target Release: | --- | ||||||
| Hardware: | All | ||||||
| OS: | Linux | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | 9.4.0-1.fc7 | Doc Type: | Bug Fix | ||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2007-03-06 15:37:14 UTC | Type: | --- | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Embargoed: | |||||||
| Attachments: |
|
||||||
This looks like a mislabeled link. Should be etc_t. restorecon /etc/rndc.key I believe this is a bug in the bind package labeling the link file, when it should only label the real file. Could you please attach an output of " #rpm -qa | egrep 'bind|caching' "? Created attachment 140902 [details]
rpm -qa | egrep 'bind|caching'
After I did the "restorecon /etc/rndc.key", I noi longer needed the local
selinux module and everything worked.
Attached is the requested info.
I can reproduce it, thanks. Could you please attach an output from "#matchpathcon /etc/rndc.key"? Output from "matchpathcon /etc/rndc.key" (which is what I think you meant to say): /etc/rndc.key system_u:object_r:dnssec_t and what context do you have for this file? (ls -Z /etc/rndc.key) Per comment #3 above, I did the "restorecon /etc/rndc.key" and that seemed to "fix" the problem. The result of "ls -Z /etc/rndc.key" now is: lrwxrwxrwx root named system_u:object_r:etc_t /etc/rndc.key -> /var/named/chroot//etc/rndc.key It's quite strange because: matchpathcon /etc/rndc.key says system_u:object_r:dnssec_t the default context for /etc/rndc.key is system_u:object_r:dnssec_t but restorecon /etc/rndc.key sets it to system_u:object_r:etc_t? I'm quite confused with it, but at least in policy is that /etc/rndc.key should have system_u:object_r:dnssec_t, right? At this point, I am not sure what /etc/rndc.key was originally set to during the install (it was a fresh install). However, with that setting, dhcpd did not work. After running "restorecon /etc/rndc.key", is is set to "system_u:object_r:etc_t" and dhcpd can update named dynamically. Perhaps one of the selinux "experts" can shed some light on the differences between matchpathcon and restorecon. /etc/rndc.key the file is labeled dnssec_t /etc/rndc.key the symbolic link is labeled etc_t. Could be fixed in bind-*9.4.0-1.fc7 |
Description of problem: I have named and dhcpd configured to allow automatic updating of system names in DNS by dhcpd. Under FC6, dhcpd startup fails because: audit(1162562248.905:8): avc: denied { read } for pid=3560 comm="dhcpd" name="rndc.key" dev=hda8 ino=1064661 scontext=root:system_r:dhcpd_t:s0 tcontext=system_u:object_r:dnssec_t:s0 tclass=lnk_file I used audit2allow to create: module dhcpd 1.0; require { class lnk_file read; type dhcpd_t; type dnssec_t; role system_r; }; allow dhcpd_t dnssec_t:lnk_file read; which when processed and loaded allowed dhcpd to start and function properly. I believe this should be a built-in option ... should this be a bug report or an RFE? Version-Release number of selected component (if applicable): FC6 plus updates as of 11/2/2006 How reproducible: yes