Bug 632311 - AVC denials upon boot (mdadm)
Summary: AVC denials upon boot (mdadm)
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: mdadm
Version: rawhide
Hardware: All
OS: Linux
low
medium
Target Milestone: ---
Assignee: Doug Ledford
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2010-09-09 16:46 UTC by Ben Boeckel
Modified: 2011-05-02 16:49 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2011-05-02 16:49:30 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

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.


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