Bug 250125 - denials for mdadm
Summary: denials for mdadm
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: mdadm
Version: 7
Hardware: All
OS: Linux
low
low
Target Milestone: ---
Assignee: Doug Ledford
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2007-07-30 15:36 UTC by Orion Poplawski
Modified: 2007-11-30 22:12 UTC (History)
1 user (show)

Fixed In Version: 2.6.4-30
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2007-10-17 19:43:07 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Orion Poplawski 2007-07-30 15:36:18 UTC
Description of problem:

I get mdadm denials when events happen on on array:

Jul 27 16:12:28 vault kernel: md: md1 stopped.
Jul 27 16:12:28 vault kernel: md: bind<sdb2>
Jul 27 16:12:28 vault kernel: md: bind<sda2>
Jul 27 16:12:28 vault kernel: md: kicking non-fresh sdb2 from array!
Jul 27 16:12:28 vault kernel: md: unbind<sdb2>
Jul 27 16:12:28 vault kernel: md: export_rdev(sdb2)
Jul 27 16:12:28 vault kernel: raid1: raid set md1 active with 1 out of 2 mirrors
Jul 27 16:12:30 vault kernel: md: md0 stopped.
Jul 27 16:12:30 vault kernel: md: bind<sdb1>
Jul 27 16:12:30 vault kernel: md: bind<sda1>
Jul 27 16:12:30 vault kernel: md: kicking non-fresh sdb1 from array!
Jul 27 16:12:30 vault kernel: md: unbind<sdb1>
Jul 27 16:12:30 vault kernel: md: export_rdev(sdb1)
Jul 27 16:12:30 vault kernel: raid1: raid set md0 active with 1 out of 2 mirrors
Jul 27 16:12:30 vault kernel: EXT3 FS on md0, internal journal
Jul 27 16:12:31 vault kernel: audit(1185574336.897:4): avc:  denied  { getattr }
for  pid=1975 comm="sh" name="root" dev=dm-0 ino=98305
scontext=system_u:system_r:mdadm_t:s0 tcontext=root:object_r:user_home_dir_t:s0
tclass=dir
Jul 27 16:12:31 vault kernel: audit(1185574336.897:5): avc:  denied  { search }
for  pid=1975 comm="sh" name="root" dev=dm-0 ino=98305
scontext=system_u:system_r:mdadm_t:s0 tcontext=root:object_r:user_home_dir_t:s0
tclass=dir
Jul 27 16:12:31 vault kernel: audit(1185574337.896:6): avc:  denied  { getattr }
for  pid=2039 comm="sh" name="root" dev=dm-0 ino=98305
scontext=system_u:system_r:mdadm_t:s0 tcontext=root:object_r:user_home_dir_t:s0
tclass=dir
Jul 27 16:12:31 vault kernel: audit(1185574337.896:7): avc:  denied  { search }
for  pid=2039 comm="sh" name="root" dev=dm-0 ino=98305
scontext=system_u:system_r:mdadm_t:s0 tcontext=root:object_r:user_home_dir_t:s0
tclass=dir

Version-Release number of selected component (if applicable):
selinux-policy-2.6.4-28.fc7
mdadm-2.6.2-4.fc7

Comment 1 Daniel Walsh 2007-07-30 15:46:19 UTC
Did you restart a service while sitting in /root?  Any idea why mdadm would be
searching this directory?

Comment 2 Orion Poplawski 2007-07-30 16:03:42 UTC
This isn't a service restarting, this is just mdadm responding to array events.

My thought would be that it might come when sending mail to root, which it does
with a popen("/usr/lib/sendmail -t","w").  Mail is successfully sent though.
Looks like it's actually a shell script that is running to generate the errors.
 CC'ing Doug Ledford to see if he has any ideas.

Comment 3 Doug Ledford 2007-07-30 19:28:09 UTC
I think Daniel's question was about whether or not the running mdadm had been
started from something other than initial bootup.  The reason isn't because you
are restarting the service now, but because if it was last started in a
directory other than /, then it gets errors reading then the shell that gets
spawned to start sendmail gets these errors as it is looking for the normal
.bash_profile and .bash_rc files.  I should be able to modify mdadm so that if
it is started in a directory other than / that it cd's into / in order to stop
these.

Comment 4 Orion Poplawski 2007-07-30 19:34:59 UTC
Well, mdmonitor is being started in the normal way via initscripts.

Comment 5 Daniel Walsh 2007-07-31 13:54:52 UTC
We can just dontaudit the call to remove the avc.



Comment 6 Daniel Walsh 2007-07-31 13:57:42 UTC
Fixed in selinux-policy-2.6.4-30


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