Description of problem: RHEL5.2-Client-20080201.nightly anaconda installation: null, random and zero device nodes in /var/named/chroot/dev have wrong security labels. Version-Release number of selected component (if applicable): bind-chroot-9.3.4-3.P1.el5 How reproducible: Always Steps to Reproduce: 1. Install RHEL5.2-Client-20080201.nightly (or anything beyond installable) with bind-chroot package included 2. Reboot 3. ls -lZ /var/named/chroot/dev/* Actual results: crw-rw---- root named system_u:object_r:named_conf_t null crw-rw---- root named system_u:object_r:named_conf_t random crw-rw---- root named system_u:object_r:named_conf_t zero Expected results: crw-rw---- root named system_u:object_r:null_device_t null crw-rw---- root named system_u:object_r:random_device_t random crw-rw---- root named system_u:object_r:zero_device_t zero Additional info: Wrong security labels on these device nodes cause an avc denial when starting named-chroot: avc: denied { getattr } for pid=3254 comm="named" path="/dev/random" dev=dm-0 ino=4821839 scontext=root:system_r:named_t:s0 tcontext=system_u:object_r:named_conf_t:s0 tclass=chr_fil e
Hm, in the end it looks that problem is also in selinux-policy. Problem is fixed on bind side by bug #253537. - Install RHEL5 and during installation (when bind and policycoreutils are installed) try run "restorecon /mnt/sysimage/var/named/chroot/dev/*" - context is bad but when I run for example "restorecon /mnt/sysimage/bin/pwd" context of pwd is good Reassigning to selinux-policy to next inspection
So anaconda install ends up with the wrong context, while installing the machine after anaconda gets it right? If you execute restorecon on the directory, does it fix the labels?
(In reply to comment #2) > So anaconda install ends up with the wrong context, while installing the machine > after anaconda gets it right? > > If you execute restorecon on the directory, does it fix the labels? When installation ends /var/named/chroot/dev/* files has wrong context. Only when you reboot after installation and fix labels manually it works as expected
Could you check to see if bind-chroot is being installed in anaconda before selinux-policy-targeted, which would cause this problem.
bind-chroot actually does install before selinux-policy-targeted (@everything installation).
That is what the problem is. There is no good way for us to fix this. If you require selinux-policy-targeted, it would work, but that is not a good idea, for people who do not want policy installed. You could add a restorecon to your init scripts, So everytime the bind service starts it fixes the context on the chroot directories.
Requiring selinux-* is bad idea. Also restorecon in initscript is bad but seems like only one possible solution. Reassigning back to bind
*** This bug has been marked as a duplicate of 253537 ***
(In reply to comment #6) > That is what the problem is. There is no good way for us to fix this. If you > require selinux-policy-targeted, it would work, but that is not a good idea, for > people who do not want policy installed. You could add a restorecon to your > init scripts, So everytime the bind service starts it fixes the context on the > chroot directories. Tomas Mraz point me to better solution. In the end I used %posttrans script in rpm and it also fixes the problem and solution is clearer