Hide Forgot
This bug has been copied from bug #1381588 and has been proposed to be backported to 7.3 z-stream (EUS).
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://rhn.redhat.com/errata/RHBA-2016-2611.html
I'm seeing this on CentOS (testing oVirt) even with newer selinux-policy packages (selinux-policy-targeted-3.13.1-102.el7_3.15.noarch.rpm) - when trying to use NFSv4.2, sanlock fails: [root@lago-basic-suite-master-host0 ~]# semanage boolean -C -l SELinux boolean State Default Description virt_use_fusefs (on , on) Allow virt to use fusefs sanlock_use_nfs (on , on) Allow sanlock to use nfs sanlock_use_samba (on , on) Allow sanlock to use samba virt_use_sanlock (on , on) Allow virt to use sanlock virt_use_samba (on , on) Allow virt to use samba sanlock_use_fusefs (on , on) Allow sanlock to use fusefs virt_use_nfs (on , on) Allow virt to use nfs ^C[root@lago-basic-suite-master-host0 ~]# audit2allow -a #============= kdump_t ============== #!!!! WARNING: 'unlabeled_t' is a base type. allow kdump_t unlabeled_t:file read; #============= sanlock_t ============== #!!!! WARNING: 'unlabeled_t' is a base type. allow sanlock_t unlabeled_t:file { open read write };
There should be no files with an unlabeled_t context. It seems that some files are mislabeled on your machine. Could you attach the output of following command? # ausearch -m avc -i -ts today
(In reply to Milos Malik from comment #12) > There should be no files with an unlabeled_t context. It seems that some > files are mislabeled on your machine. Could you attach the output of > following command? > > # ausearch -m avc -i -ts today [root@lago-basic-suite-master-host1 ~]# ausearch -m avc -i -ts today ---- type=SYSCALL msg=audit(03/13/2017 07:55:38.523:195) : arch=x86_64 syscall=open success=no exit=EACCES(Permission denied) a0=0x7ffefd216f5f a1=O_RDONLY a2=0x1b6 a3=0x7ffefd215610 items=0 ppid=1182 pid=10397 auid=unset uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=(none) ses=unset comm=kexec exe=/usr/sbin/kexec subj=system_u:system_r:kdump_t:s0 key=(null) type=AVC msg=audit(03/13/2017 07:55:38.523:195) : avc: denied { read } for pid=10397 comm=kexec name=vmlinuz-3.10.0-514.10.2.el7.x86_64 dev="vda1" ino=167977 scontext=system_u:system_r:kdump_t:s0 tcontext=system_u:object_r:unlabeled_t:s0 tclass=file ---- type=SYSCALL msg=audit(03/13/2017 07:55:38.523:196) : arch=x86_64 syscall=open success=no exit=EACCES(Permission denied) a0=0x7ffefd216f5f a1=O_RDONLY a2=0x1b6 a3=0x24 items=0 ppid=1182 pid=10397 auid=unset uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=(none) ses=unset comm=kexec exe=/usr/sbin/kexec subj=system_u:system_r:kdump_t:s0 key=(null) type=AVC msg=audit(03/13/2017 07:55:38.523:196) : avc: denied { read } for pid=10397 comm=kexec name=vmlinuz-3.10.0-514.10.2.el7.x86_64 dev="vda1" ino=167977 scontext=system_u:system_r:kdump_t:s0 tcontext=system_u:object_r:unlabeled_t:s0 tclass=file ---- type=SYSCALL msg=audit(03/13/2017 08:04:08.269:1597) : arch=x86_64 syscall=open success=no exit=EACCES(Permission denied) a0=0x7ff87c0009c8 a1=O_RDWR|O_DSYNC|O_DIRECT|__O_SYNC a2=0x0 a3=0x0 items=0 ppid=1 pid=15365 auid=unset uid=sanlock gid=sanlock euid=sanlock suid=sanlock fsuid=sanlock egid=sanlock sgid=sanlock fsgid=sanlock tty=(none) ses=unset comm=sanlock exe=/usr/sbin/sanlock subj=system_u:system_r:sanlock_t:s0-s0:c0.c1023 key=(null) type=AVC msg=audit(03/13/2017 08:04:08.269:1597) : avc: denied { read write open } for pid=15365 comm=sanlock path=/rhev/data-center/mnt/192.168.201.3:_exports_nfs_share1/2cb7b5dc-d09e-424b-b66a-a7a65ba6c9b2/dom_md/ids dev="0:40" ino=67108931 scontext=system_u:system_r:sanlock_t:s0-s0:c0.c1023 tcontext=system_u:object_r:unlabeled_t:s0 tclass=file ---- type=SYSCALL msg=audit(03/13/2017 08:06:10.310:2170) : arch=x86_64 syscall=open success=no exit=EACCES(Permission denied) a0=0x7fc2a477234e a1=O_RDONLY a2=0x0 a3=0x3 items=0 ppid=1179 pid=29272 auid=root uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=(none) ses=10 comm=sshd exe=/usr/sbin/sshd subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 key=(null) type=AVC msg=audit(03/13/2017 08:06:10.310:2170) : avc: denied { read } for pid=29272 comm=sshd name=lastlog dev="dm-0" ino=9120378 scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:virt_log_t:s0 tclass=file ---- type=SYSCALL msg=audit(03/13/2017 08:06:10.551:2179) : arch=x86_64 syscall=open success=no exit=EACCES(Permission denied) a0=0x7f159db4a34e a1=O_RDONLY a2=0x0 a3=0x3 items=0 ppid=1179 pid=29275 auid=root uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=(none) ses=11 comm=sshd exe=/usr/sbin/sshd subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 key=(null) type=AVC msg=audit(03/13/2017 08:06:10.551:2179) : avc: denied { read } for pid=29275 comm=sshd name=lastlog dev="dm-0" ino=9120378 scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:virt_log_t:s0 tclass=file ---- type=SYSCALL msg=audit(03/13/2017 08:06:13.676:2230) : arch=x86_64 syscall=open success=no exit=EACCES(Permission denied) a0=0x7fb299eea34e a1=O_RDONLY a2=0x0 a3=0x3 items=0 ppid=1179 pid=29291 auid=root uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=(none) ses=12 comm=sshd exe=/usr/sbin/sshd subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 key=(null) type=AVC msg=audit(03/13/2017 08:06:13.676:2230) : avc: denied { read } for pid=29291 comm=sshd name=lastlog dev="dm-0" ino=9120378 scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:virt_log_t:s0 tclass=file ---- type=SYSCALL msg=audit(03/13/2017 08:06:13.865:2239) : arch=x86_64 syscall=open success=no exit=EACCES(Permission denied) a0=0x7f358984834e a1=O_RDONLY a2=0x0 a3=0x3 items=0 ppid=1179 pid=29308 auid=root uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=(none) ses=13 comm=sshd exe=/usr/sbin/sshd subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 key=(null) type=AVC msg=audit(03/13/2017 08:06:13.865:2239) : avc: denied { read } for pid=29308 comm=sshd name=lastlog dev="dm-0" ino=9120378 scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:virt_log_t:s0 tclass=file ---- type=SYSCALL msg=audit(03/13/2017 08:07:46.406:2358) : arch=x86_64 syscall=open success=no exit=EACCES(Permission denied) a0=0x7f1537a0234e a1=O_RDONLY a2=0x0 a3=0x3 items=0 ppid=1179 pid=29572 auid=root uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=(none) ses=14 comm=sshd exe=/usr/sbin/sshd subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 key=(null) type=AVC msg=audit(03/13/2017 08:07:46.406:2358) : avc: denied { read } for pid=29572 comm=sshd name=lastlog dev="dm-0" ino=9120378 scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:virt_log_t:s0 tclass=file ---- type=SYSCALL msg=audit(03/13/2017 08:07:46.736:2387) : arch=x86_64 syscall=open success=no exit=EACCES(Permission denied) a0=0x7f9c59cee34e a1=O_RDONLY a2=0x0 a3=0x3 items=0 ppid=1179 pid=29580 auid=root uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=(none) ses=15 comm=sshd exe=/usr/sbin/sshd subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 key=(null) type=AVC msg=audit(03/13/2017 08:07:46.736:2387) : avc: denied { read } for pid=29580 comm=sshd name=lastlog dev="dm-0" ino=9120378 scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:virt_log_t:s0 tclass=file A bit about this 'host' - it's a nested-virt host, that as part of its provisioning (via virt-sysprep) either does or does not (tried both) get fully updated, but also run selinux-relabeling - which I can see taking place: [ 284.0] Setting passwords [ 285.6] SELinux relabelling [ 298.9] Performing "lvm-uuids" .. So it's happening offline even.
Where are the unlabeled_t files located? # find / -type f -context \*unlabeled_t\*
(In reply to Milos Malik from comment #14) > Where are the unlabeled_t files located? > > # find / -type f -context \*unlabeled_t\* [root@lago-basic-suite-master-host0 ~]# find / -type f -context \*unlabeled_t\* /boot/.vmlinuz-3.10.0-514.2.2.el7.x86_64.hmac /boot/System.map-3.10.0-514.2.2.el7.x86_64 /boot/config-3.10.0-514.2.2.el7.x86_64 /boot/symvers-3.10.0-514.2.2.el7.x86_64.gz /boot/vmlinuz-3.10.0-514.2.2.el7.x86_64 /boot/initramfs-3.10.0-514.2.2.el7.x86_64.img /boot/initramfs-0-rescue-6659efcb4905440bbd62df38e20d963e.img /boot/vmlinuz-0-rescue-6659efcb4905440bbd62df38e20d963e /tmp/builder.log /rhev/data-center/mnt/192.168.201.3:_exports_nfs_share1/__DIRECT_IO_TEST__ /rhev/data-center/mnt/192.168.201.3:_exports_nfs_share1/3ec0bfc8-2c74-473e-94a1-532cd26d04b4/dom_md/xleases /rhev/data-center/mnt/192.168.201.3:_exports_nfs_share1/3ec0bfc8-2c74-473e-94a1-532cd26d04b4/dom_md/ids /rhev/data-center/mnt/192.168.201.3:_exports_nfs_share1/3ec0bfc8-2c74-473e-94a1-532cd26d04b4/dom_md/inbox /rhev/data-center/mnt/192.168.201.3:_exports_nfs_share1/3ec0bfc8-2c74-473e-94a1-532cd26d04b4/dom_md/outbox /rhev/data-center/mnt/192.168.201.3:_exports_nfs_share1/3ec0bfc8-2c74-473e-94a1-532cd26d04b4/dom_md/leases /rhev/data-center/mnt/192.168.201.3:_exports_nfs_share1/3ec0bfc8-2c74-473e-94a1-532cd26d04b4/dom_md/metadata
Following command will repair SELinux contexts on all files under /boot: # restorecon -Rv /boot Before we repair contexts on /rhev/data-center/mnt/ files using the same command, I would like to know if there are any SELinux fcontext equivalences set: # matchpathcon /rhev/data-center/mnt
(In reply to Milos Malik from comment #16) > Following command will repair SELinux contexts on all files under /boot: > > # restorecon -Rv /boot Thanks - I wonder why I need to run it. > > Before we repair contexts on /rhev/data-center/mnt/ files using the same > command, I would like to know if there are any SELinux fcontext equivalences > set: > > # matchpathcon /rhev/data-center/mnt [root@lago-basic-suite-master-host0 ~]# matchpathcon /rhev/data-center/mnt /rhev/data-center/mnt <<none>>
Following command sets up the same label for all file-system objects under /rhev/data-center/mnt. Similar change is being introduced to RHEL-7.4 now: # semanage fcontext -a -t mnt_t '/rhev/data-center/mnt(/.*)?' Following command shows which files/directories will be relabeled, but won't do the relabeling: # restorecon -Rvn /rhev/data-center/mnt Following command will do the relabeling: # restorecon -Rv /rhev/data-center/mnt
(In reply to Milos Malik from comment #18) > Following command sets up the same label for all file-system objects under > /rhev/data-center/mnt. Similar change is being introduced to RHEL-7.4 now: > # semanage fcontext -a -t mnt_t '/rhev/data-center/mnt(/.*)?' > > Following command shows which files/directories will be relabeled, but won't > do the relabeling: > # restorecon -Rvn /rhev/data-center/mnt > > Following command will do the relabeling: > # restorecon -Rv /rhev/data-center/mnt Nir - is this something we need to perform when creating /rhev/data-center ?
Milo, do we need to run restorecon when creating /rhev/data-center, or we should get the correct selinux label since selinux policy has a builtin rule or this path?
I always run restorecon when I find unlabeled_t object on a file-system. Such labels should not happen.