Hide Forgot
Description of problem: If SELinux is in enforcing mode, the start of named fails if named is started using: $ sudo /etc/init.d/named start Starting named: named: chroot(): Permission denied [FAILED] This error does NOT occur if named is started directly using: $ sudo /usr/sbin/named -u named -t /var/named/chroot Therefore I assume, the error is caused by the script /etc/init.d/named Version-Release number of selected component (if applicable): RHEL 5.4 2.6.18-164.2.1.el5 x86_64 libselinux-1.33.4-5.5.el5 libselinux-utils-1.33.4-5.5.el5 selinux-policy-2.4.6-255.el5 selinux-policy-targeted-2.4.6-255.el5 Steps to Reproduce: 1. sudo setenforce Enforcing 2. sudo /etc/init.d/named start Actual results: the error message above Expected results: named running Additional info: Policy can be created and installed manually: $ sudo /etc/init.d/named start $ sudo grep avc /var/log/audit/audit.log | grep dac_read_search | tail -1 | audit2allow -M mynamed $ sudo semodule -i mynamed.pp $ cat mynamed.te module mynamed 1.0; require { type named_t; class capability dac_read_search; } #============= named_t ============== allow named_t self:capability dac_read_search;
Is the ownership correct in the /var/chroot directory. dac_read_search means that root is trying to read files that it does not have read access to.
I'm wondering if it might be the difference between running "/etc/init.d/named start" and "service named start". I've asked Ruben to try if the service command works, as that should execute the script with a sane environment (from "/" as working directory, instead of wherever $cwd was when he ran the script).
BTW: these are the ownerships dwalsh asked for: [janfrode@ns1ext ~]$ sudo ls -ldZ /var/named drwxr-x--- named hostmaster system_u:object_r:named_zone_t /var/named [janfrode@ns1ext ~]$ sudo ls -ldZ /var/named/chroot drwxr-x--- named hostmaster system_u:object_r:named_conf_t /var/named/chroot Group "hostmaster" is a local modification, so not what standard RHEL5 would use for these. I think the default is group "named".
Answer to comment#2: With "sudo service named start" the same error occurs.
BTW: /var/named/chroot is a separate volume/fs: [janfrode@ns1ext ~]$ df -h /var/named/chroot Filesystem Size Used Avail Use% Mounted on /dev/mapper/rootvg-chrootlv 6.9G 518M 6.1G 8% /var/named/chroot that might be relevant...
Since you changed the ownership of the directories from root to named you need to add this additional access.
Great, thanks! I have no idea why we've changed this permission, so we should probably change it back to the default. Especially since the bind-chroot package quite often will reset permissions on upgrades anyway..