Bug 431202
Summary: | Wrong security labels on /var/named/chroot/dev/* | ||
---|---|---|---|
Product: | Red Hat Enterprise Linux 5 | Reporter: | Milan Zázrivec <mzazrivec> |
Component: | bind | Assignee: | Adam Tkac <atkac> |
Status: | CLOSED DUPLICATE | QA Contact: | |
Severity: | low | Docs Contact: | |
Priority: | low | ||
Version: | 5.2 | CC: | atkac, ovasik |
Target Milestone: | rc | ||
Target Release: | --- | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2008-02-08 09:48:25 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: |
Description
Milan Zázrivec
2008-02-01 14:54:01 UTC
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 |