| Summary: | inconsistent labeling of /var/named/chroot/usr/lib/bind and /usr/lib/bind | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Eddie Lania <eddie> |
| Component: | selinux-policy-targeted | Assignee: | Miroslav Grepl <mgrepl> |
| Status: | CLOSED WONTFIX | QA Contact: | Ben Levenson <benl> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 16 | CC: | dwalsh |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2013-02-14 02:01:18 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
|
Description
Eddie Lania
2012-01-15 16:42:05 UTC
If you execute $ chcon -R -t lib_t /var/named/chroot/usr/lib/bind does it work correctly? No: [root@ls2ka ~]# chcon -R -t lib_t /var/named/chroot/usr/lib/bind [root@ls2ka ~]# /sbin/restorecon -v -v -R /var/named/chroot/usr/lib/bind /sbin/restorecon reset /var/named/chroot/usr/lib/bind context system_u:object_r:lib_t:s0->system_u:object_r:named_conf_t:s0 [root@ls2ka ~]# /sbin/restorecon -v -v -R /usr/lib/bind /sbin/restorecon reset /usr/lib/bind context system_u:object_r:named_conf_t:s0->system_u:object_r:lib_t:s0 I thought BIND. restorecon will fix the label because of chcon. Hi Miroslav, /var/named/chroot/usr/lib/bind is hard linked from /usr/lib/bind during execution of named. So, isn't it then supposed to be that it inherits the context of /usr/lib/bind? If so, then why is a restorecon then changing it from object_r:lib_t to object_r:named_conf_t? Regards, Eddie. Miroslav, Apparently, there's more wrong here: The following is from the problematic system: [root@ls2ka ~]# ls -lisa --lcontext /var/named/chroot/usr total 12 1479933 4 drwxr-xr-x. 3 unconfined_u:object_r:named_conf_t:s0 root root 4096 Aug 11 2009 . 1480115 4 drwxr-x---. 6 system_u:object_r:named_conf_t:s0 root named 4096 Nov 16 20:26 .. 1480114 4 drwxr-xr-x. 3 unconfined_u:object_r:named_conf_t:s0 root root 4096 Aug 11 2009 lib [root@ls2ka ~]# ls -lisa --lcontext /var/named/chroot/usr/lib total 12 1480114 4 drwxr-xr-x. 3 unconfined_u:object_r:named_conf_t:s0 root root 4096 Aug 11 2009 . 1479933 4 drwxr-xr-x. 3 unconfined_u:object_r:named_conf_t:s0 root root 4096 Aug 11 2009 .. 1261316 4 drwxr-x---. 2 system_u:object_r:lib_t:s0 root named 4096 Nov 16 20:26 bind [root@ls2ka ~]# ls -lisa --lcontext /var/named total 24 1480100 4 drwxr-x---. 6 system_u:object_r:named_zone_t:s0 root named 4096 Dec 18 12:38 . 1267281 4 drwxr-xr-x. 25 system_u:object_r:var_t:s0 root root 4096 Jan 10 10:09 .. 1480115 4 drwxr-x---. 6 system_u:object_r:named_conf_t:s0 root named 4096 Nov 16 20:26 chroot 1480101 4 drwxrwx---. 2 system_u:object_r:named_cache_t:s0 named named 4096 Nov 16 20:26 data 1480102 4 drwxrwx---. 2 system_u:object_r:named_cache_t:s0 named named 4096 Nov 16 20:26 dynamic 1480107 4 drwxrwx---. 2 system_u:object_r:named_cache_t:s0 named named 4096 Nov 16 20:26 slaves [root@ls2ka ~]# And from another system that has just been freshly installed: [root@zeus ~]# ls -lisa --lcontext /var/named/chroot/usr total 12 919084 4 drwxr-xr-x. 3 system_u:object_r:named_conf_t:s0 root root 4096 Dec 10 20:29 . 919081 4 drwxr-x---. 6 system_u:object_r:named_conf_t:s0 root named 4096 Dec 10 20:29 .. 919085 4 drwxr-xr-x. 3 system_u:object_r:named_conf_t:s0 root root 4096 Dec 10 20:29 lib64 [root@zeus ~]# ls -lisa --lcontext /var/named/chroot/usr/lib64/ total 12 919085 4 drwxr-xr-x. 3 system_u:object_r:named_conf_t:s0 root root 4096 Dec 10 20:29 . 919084 4 drwxr-xr-x. 3 system_u:object_r:named_conf_t:s0 root root 4096 Dec 10 20:29 .. 3287094 4 drwxr-xr-x. 2 system_u:object_r:lib_t:s0 root root 4096 Nov 16 20:26 bind [root@zeus ~]# ls -lisa --lcontext /var/named total 24 657133 4 drwxr-x---. 6 system_u:object_r:named_zone_t:s0 root named 4096 Dec 17 15:52 . 655361 4 drwxr-xr-x. 22 system_u:object_r:var_t:s0 root root 4096 Dec 13 14:02 .. 919081 4 drwxr-x---. 6 system_u:object_r:named_conf_t:s0 root named 4096 Dec 10 20:29 chroot 657134 4 drwxrwx---. 2 system_u:object_r:named_cache_t:s0 named named 4096 Nov 16 20:26 data 788227 4 drwxrwx---. 2 system_u:object_r:named_cache_t:s0 named named 4096 Nov 16 20:26 dynamic 919080 4 drwxrwx---. 2 system_u:object_r:named_cache_t:s0 named named 4096 Nov 16 20:26 slaves [root@zeus ~]# The first system has been updated from fc14 to fc16. Can you tell me what is wrong and how I should correct it? Thank you. Regards, Eddie. (In reply to comment #4) > Hi Miroslav, > > > /var/named/chroot/usr/lib/bind is hard linked from /usr/lib/bind during > execution of named. > > So, isn't it then supposed to be that it inherits the context of /usr/lib/bind? > > If so, then why is a restorecon then changing it from object_r:lib_t to > object_r:named_conf_t? > > Regards, > > Eddie. This is a problem with hardlinks. We need to have the same label for both location. I will fix this labeling. Fedora 16 changed to end-of-life (EOL) status on 2013-02-12. Fedora 16 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed. |