Bug 632311

Summary: AVC denials upon boot (mdadm)
Product: [Fedora] Fedora Reporter: Ben Boeckel <fedora>
Component: mdadmAssignee: Doug Ledford <dledford>
Status: CLOSED CURRENTRELEASE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: low    
Version: rawhideCC: dledford, dwalsh
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2011-05-02 16:49:30 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 Ben Boeckel 2010-09-09 16:46:16 UTC
Description of problem:
Upon boot, I'm getting some AVC messages upon boot (pasted below). This machine has hardware RAID1 enabled. /var/tmp and /tmp are modified to be tmpfs and I have a few autofs mounts as well (none should be triggered at boot however). Is there a way to get the information from setroubleshoot from the command line?

# ausearch -m avc -ts today
----
time->Thu Sep  9 12:33:26 2010
type=SYSCALL msg=audit(1284050006.803:25): arch=c000003e syscall=262 success=yes exit=0 a0=3 a1=1af552b a2=7fff7f25d720 a3=100 items=0 ppid=1 pid=1260 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="mdadm" exe="/sbin/mdadm" subj=system_u:system_r:mdadm_t:s0 key=(null)
type=AVC msg=audit(1284050006.803:25): avc:  denied  { getattr } for  pid=1260 comm="mdadm" path="/dev/hugepages" dev=hugetlbfs ino=9642 scontext=system_u:system_r:mdadm_t:s0 tcontext=system_u:object_r:hugetlbfs_t:s0 tclass=dir
----
time->Thu Sep  9 12:33:26 2010
type=SYSCALL msg=audit(1284050006.803:26): arch=c000003e syscall=257 success=yes exit=5 a0=3 a1=1af4285 a2=10800 a3=0 items=0 ppid=1 pid=1260 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="mdadm" exe="/sbin/mdadm" subj=system_u:system_r:mdadm_t:s0 key=(null)
type=AVC msg=audit(1284050006.803:26): avc:  denied  { open } for  pid=1260 comm="mdadm" name="/" dev=hugetlbfs ino=9642 scontext=system_u:system_r:mdadm_t:s0 tcontext=system_u:object_r:hugetlbfs_t:s0 tclass=dir
type=AVC msg=audit(1284050006.803:26): avc:  denied  { read } for  pid=1260 comm="mdadm" name="/" dev=hugetlbfs ino=9642 scontext=system_u:system_r:mdadm_t:s0 tcontext=system_u:object_r:hugetlbfs_t:s0 tclass=dir
----
time->Thu Sep  9 12:33:26 2010
type=SYSCALL msg=audit(1284050006.804:27): arch=c000003e syscall=262 success=yes exit=0 a0=5 a1=1afd32b a2=7fff7f25d5a0 a3=100 items=0 ppid=1 pid=1260 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="mdadm" exe="/sbin/mdadm" subj=system_u:system_r:mdadm_t:s0 key=(null)
type=AVC msg=audit(1284050006.804:27): avc:  denied  { getattr } for  pid=1260 comm="mdadm" path="/dev/md/md0.sock" dev=devtmpfs ino=12559 scontext=system_u:system_r:mdadm_t:s0 tcontext=system_u:object_r:device_t:s0 tclass=sock_file
----
time->Thu Sep  9 12:33:31 2010
type=SYSCALL msg=audit(1284050011.362:32): arch=c000003e syscall=6 success=no exit=-13 a0=7f6ed1f2d5ae a1=7fff6de9e8c0 a2=7fff6de9e8c0 a3=0 items=0 ppid=1 pid=1234 auid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=tty1 ses=1 comm="login" exe="/bin/login" subj=system_u:system_r:local_login_t:s0-s0:c0.c1023 key=(null)
type=AVC msg=audit(1284050011.362:32): avc:  denied  { getattr } for  pid=1234 comm="login" path="/sys/fs/cgroup" dev=tmpfs ino=9197 scontext=system_u:system_r:local_login_t:s0-s0:c0.c1023 tcontext=system_u:object_r:tmpfs_t:s0 tclass=dir

Version-Release number of selected component (if applicable):
selinux-policy-targeted-3.9.0-2.fc14.noarch
mdadm-3.1.3-0.git20100722.2.fc14.x86_64

How reproducible:
Always

Comment 1 Ben Boeckel 2010-09-09 16:46:38 UTC
CC'ing dwalsh.

Comment 2 Daniel Walsh 2010-09-09 17:48:43 UTC
The first and last are fixed in  selinux-policy-3.9.3-2.fc14 And the middle one will not show any more.  But what is /dev/md/md0.sock?  Is this created by mdadm?  Do other programs talk to it?

Comment 3 Ben Boeckel 2010-09-09 18:07:32 UTC
Not sure. Here's information about:

# lsof | grep md0.sock
mdmon      1219   root    3u     unix 0xffff8802306bb800          0t0      12558 /dev/md/md0.sock
# stat /dev/md/md0.sock 
  File: `/dev/md/md0.sock'
  Size: 0               Blocks: 0          IO Block: 4096   socket
Device: 5h/5d   Inode: 12559       Links: 1
Access: (0755/srwxr-xr-x)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2010-09-09 12:33:26.356794006 -0400
Modify: 2010-09-09 12:33:26.356794006 -0400
Change: 2010-09-09 12:33:26.356794006 -0400

Comment 4 Doug Ledford 2010-09-09 18:12:48 UTC
Recent changes to mdadm include the fact that mdmon now stores its sock and pid files in /dev/md/.  This was done because if your root device is on an intel matrix raid device, these files need to be writable from the time before root is writable until after it goes back to read-only on shutdown.  The pid file is read by mdmon, initscripts, and mdadm.  The sock file is created by mdmon and accessed by mdadm and mdmon.

Comment 5 Daniel Walsh 2010-09-09 18:43:04 UTC
Fixed in selinux-policy-3.9.3-4.fc14

Comment 6 Doug Ledford 2011-05-02 16:49:30 UTC
Fixed long ago but bug was not autoclosed.