Claude Jones wrote:
In a different thread "Re: Package managers gone haywire! yum, apt, rpm: pam
is totally borked" I've described a series of failures that occurred with my
package management system beginning on Saturday. There were 36 hours+ of
attempts to repair this which involved multiple attempted updates that failed
with frozen GUI's in Smart, Yumex, and Synaptic and command line errors
including multiple segfaults when updates were attempted. Gradually, all the
updates were eventually done.
Two of the packages that were involved were selinux-policy and
selinux-policy-targeted. While most issues seem to be getting resolved,
running with selinux enabled is impossible. If I enable it, I get a flood of
error messages on boot up and eventually, Fedora drops me to a shell and
suggests a file system check or Ctl-D to continue; Ctl-D just reboots the
machine with the same results; fsck always returns a clean file system with
no reported problems. I've removed and reinstalled selinux-policy and
selinux-policy-targeted but that didn't change matters. touch /.autorelabel
is impossible, because it never gets to that point. I looked at removing
other parts of selinux but they involve dependencies on every other package
installed, it seems like. Is there any other tool I can use to repair the
selinux installation? As I'm looking closer at last night's log after
attempting to start with selinux running, I see that all the failures have to
do with /dev entries, hardware -- I noticed during the bootup that the
messages flying by seemed to largely associated with udev problems; here's an
example of three of the failure messages:
type=AVC msg=audit(1181875931.670:6570): avc: denied { getattr } for
pid=9482 comm="rpc.mountd" name="audio" dev=tmpfs ino=6018
scontext=system_u:system_r:nfsd_t:s0
tcontext=system_u:object_r:sound_device_t:s0 tclass=chr_file
type=SYSCALL msg=audit(1181875931.670:6570): arch=40000003 syscall=195
success=no exit=-13 a0=bf852054 a1=bf851f30 a2=873ff4 a3=3 items=0 ppid=1
pid=9482 auid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0
tty=(none) comm="rpc.mountd" exe="/usr/sbin/rpc.mountd"
subj=system_u:system_r:nfsd_t:s0 key=(null)
type=AVC_PATH msg=audit(1181875931.670:6570): path="/dev/audio"
type=AVC msg=audit(1181875931.670:6571): avc: denied { getattr } for
pid=9482 comm="rpc.mountd" name="mixer" dev=tmpfs ino=6006
scontext=system_u:system_r:nfsd_t:s0
tcontext=system_u:object_r:sound_device_t:s0 tclass=chr_file
type=SYSCALL msg=audit(1181875931.670:6571): arch=40000003 syscall=195
success=no exit=-13 a0=bf852054 a1=bf851f30 a2=873ff4 a3=3 items=0 ppid=1
pid=9482 auid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0
tty=(none) comm="rpc.mountd" exe="/usr/sbin/rpc.mountd"
subj=system_u:system_r:nfsd_t:s0 key=(null)
type=AVC_PATH msg=audit(1181875931.670:6571): path="/dev/mixer"
type=AVC msg=audit(1181875931.670:6572): avc: denied { getattr } for
pid=9482 comm="rpc.mountd" name="dsp" dev=tmpfs ino=5980
scontext=system_u:system_r:nfsd_t:s0
tcontext=system_u:object_r:sound_device_t:s0 tclass=chr_file
type=SYSCALL msg=audit(1181875931.670:6572): arch=40000003 syscall=195
success=no exit=-13 a0=bf852054 a1=bf851f30 a2=873ff4 a3=3 items=0 ppid=1
pid=9482 auid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0
tty=(none) comm="rpc.mountd" exe="/usr/sbin/rpc.mountd"
subj=system_u:system_r:nfsd_t:s0 key=(null)
type=AVC_PATH msg=audit(1181875931.670:6572): path="/dev/dsp"
type=AVC msg=audit(1181875931.670:6573): avc: denied { getattr } for
pid=9482 comm="rpc.mountd" name="adsp" dev=tmpfs ino=5946
scontext=system_u:system_r:nfsd_t:s0
tcontext=system_u:object_r:sound_device_t:s0 tclass=chr_file
type=SYSCALL msg=audit(1181875931.670:6573): arch=40000003 syscall=195
success=no exit=-13 a0=bf852054 a1=bf851f30 a2=873ff4 a3=3 items=0 ppid=1
pid=9482 auid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0
tty=(none) comm="rpc.mountd" exe="/usr/sbin/rpc.mountd"
subj=system_u:system_r:nfsd_t:s0 key=(null)
type=AVC_PATH msg=audit(1181875931.670:6573): path="/dev/adsp"
Does this make sense to anyone? Is this a udev problem, a selinux problem, or
something else entirely? With selinux disabled, things seem to back to normal
this morning
I don't think I ever mentioned this in all these trouble reports - this is F7
running on a 2.8 GHz P4 with 1 GB of ram - Windows XP is also installed on
this box, and it runs perfectly. My F7 installation is about two weeks old.
Are you sharing /dev via nfs?
