Bug 838574

Summary: sedispatch fail loop
Product: [Fedora] Fedora Reporter: Bruno Wolff III <bruno>
Component: selinux-policyAssignee: Miroslav Grepl <mgrepl>
Status: CLOSED NOTABUG QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: rawhideCC: bruno, dominick.grift, dwalsh, manisandro, mgrepl
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2012-07-10 10:49:35 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Bruno Wolff III 2012-07-09 13:58:09 UTC
Description of problem:
While booting sedispatch went into a loop causing continual writes to my audit log until I set the system in permissive. I started a relabel (which hasn't finished yet). I also tried going back to enforcing and the looping did not (at least so far) restart.
The auidt messages are:
type=AVC msg=audit(1341840269.794:141894): avc:  denied  { read } for  pid=1334 
comm="sedispatch" name="run" dev="dm-1" ino=1835144 scontext=system_u:system_r:a
udisp_t:s0 tcontext=unconfined_u:object_r:var_t:s0 tclass=lnk_file
type=SYSCALL msg=audit(1341840269.794:141894): arch=40000003 syscall=102 success
=no exit=-13 a0=3 a1=bfa81b90 a2=48cbeff4 a3=bfa81bce items=0 ppid=1303 pid=1334
 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(no
ne) ses=4294967295 comm="sedispatch" exe="/usr/sbin/sedispatch" subj=system_u:sy
stem_r:audisp_t:s0 key=(null)

Version-Release number of selected component (if applicable):
selinux-policy-3.11.0-8.fc18.noarch
setroubleshoot-server-3.1.12-3.fc18.i686

How reproducible:
I am not sure yet.

Comment 1 Bruno Wolff III 2012-07-10 10:49:35 UTC
This seems to have been fixed by a relabel (or less likely a package update).
Most likely the labelling got messed up while I was trying to recover from the recent dracut issue. Anyway, this seems resolved now.