Bugzilla (bugzilla.redhat.com) will be under maintenance for infrastructure upgrades and will not be available on July 31st between 12:30 AM - 05:30 AM UTC. We appreciate your understanding and patience. You can follow status.redhat.com for details.
Bug 527384 - SELinux policy missing for /etc/init.d/named
Summary: SELinux policy missing for /etc/init.d/named
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: selinux-policy-targeted
Version: 5.4
Hardware: x86_64
OS: Linux
low
low
Target Milestone: ---
: ---
Assignee: Daniel Walsh
QA Contact: BaseOS QE
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2009-10-06 07:39 UTC by Ruben Saar
Modified: 2009-10-08 01:26 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2009-10-07 17:06:25 UTC
Target Upstream Version:


Attachments (Terms of Use)

Description Ruben Saar 2009-10-06 07:39:53 UTC
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;

Comment 1 Daniel Walsh 2009-10-06 14:09:46 UTC
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.

Comment 2 Jan-Frode Myklebust 2009-10-07 00:36:15 UTC
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).

Comment 3 Jan-Frode Myklebust 2009-10-07 01:16:04 UTC
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".

Comment 4 Ruben Saar 2009-10-07 07:52:36 UTC
Answer to comment#2:
With "sudo service named start" the same error occurs.

Comment 5 Jan-Frode Myklebust 2009-10-07 13:58:03 UTC
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...

Comment 6 Daniel Walsh 2009-10-07 17:06:25 UTC
Since you changed the ownership of the directories from root to named you need to add this additional access.

Comment 7 Jan-Frode Myklebust 2009-10-08 01:26:36 UTC
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..


Note You need to log in before you can comment on or make changes to this bug.