Bug 632311 - AVC denials upon boot (mdadm)
AVC denials upon boot (mdadm)
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: mdadm (Show other bugs)
rawhide
All Linux
low Severity medium
: ---
: ---
Assigned To: Doug Ledford
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2010-09-09 12:46 EDT by Ben Boeckel
Modified: 2011-05-02 12:49 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2011-05-02 12:49:30 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Ben Boeckel 2010-09-09 12:46:16 EDT
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 12:46:38 EDT
CC'ing dwalsh.
Comment 2 Daniel Walsh 2010-09-09 13:48:43 EDT
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 14:07:32 EDT
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 14:12:48 EDT
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 14:43:04 EDT
Fixed in selinux-policy-3.9.3-4.fc14
Comment 6 Doug Ledford 2011-05-02 12:49:30 EDT
Fixed long ago but bug was not autoclosed.

Note You need to log in before you can comment on or make changes to this bug.