Description of problem: 'service dhcpd start' fails. Further investigation show this in /var/log/messages: Apr 15 11:53:55 bach setroubleshoot: SELinux is preventing dhcpd (dhcpd_t) "append" to /var/log/cobbler/cobbler.log (var_log_t). For complete SELinux messages. run sealert -l dd7f4867-fa8e-4258-a367-8dead2c93d52 Actual results: DHCP server is not starting Expected results: DHCP server should start Additional info: I am working in a fresh Fedora 8 installation with updates.
Interesting. setroubleshoot seems to be confused here as a cobbler generated dhcpd.conf does not make ANY references to cobbler.log -- cobbler basically generates the dhcp.conf and then /sbin/service restarts it. I would make the required audit2allow commands to allow this to go through, and report this problem with setroubleshoot. (Is it possible you have modified your dhcp configuration to write to that file?)
Yes, I can also see this lack of realationship. But I am getting this: Apr 15 12:41:09 bach setroubleshoot: SELinux is preventing dhcpd (dhcpd_t) "append" to /var/log/cobbler/cobbler.log (var_log_t). For complete SELinux messages. run sealert -l dd7f4867-fa8e-4258-a367-8dead2c93d52 And this is my (cobbler-generated) dhcpd.conf file: # ****************************************************************** # Cobbler managed dhcpd.conf file # generated from cobbler dhcp.conf template (Tue Apr 15 15:41:07 2008) # ****************************************************************** ddns-update-style interim; allow booting; allow bootp; ignore client-updates; set vendorclass = option vendor-class-identifier; subnet 192.168.234.0 netmask 255.255.255.0 { option routers 192.168.234.2; option subnet-mask 255.255.255.0; range dynamic-bootp 192.168.234.200 192.168.234.254; option domain-name "isc.br.ibm.com"; filename "/pxelinux.0"; default-lease-time 21600; max-lease-time 43200; next-server 192.168.234.50; } Anyway, forgive me, this was not the problem. I had a wrong IP range on DHCP and this was the real issue. But the SELinux message appeared bigger in front of me so the real problem message looked invisible :-)
Right, cobbler has nothing running with dhcp_t context. It runs unconfined. We do have to do some things in koan to ensure Xen files get labelled correctly, but that's it. Definitely report setroubleshoot's confusion though. Cobbler is the top level process but it's running unconfined_t and restarting a service (via a system call) that should have dhcp_t context, but at no point does dhcp know anything about Cobbler's log file.