The problem is you have an unlabled file "ior" on your system the kernel reports
this with the file_t context. This could indicate a major mislabeled machine.
YOu can fix the entire systems labeling by executing
# touch /.autorelabel; reboot

If you just added a disk you could run

# restorecon -R -v DISKMOUNTPOINT

Once you fix the labeling the problem should work fine.

-------------------------------------------------------------------------------------------------------------
I tried the .autorelabel thing, and I just did a search of the entire file
system for a file called "ior". Nothing. Are you certain of these diagnostics?

The system has been rebooted, and I've turned SE Linux to Permissive mode to
avoid any further problems.

This is a fresh install on a VM with no "new" disks. Perhaps somewhere along the
lines of upgrading from 9 alpha something became corrupt? SE Linux labels were

not applied for some reason?


-------------------------------------------------------------------------------------------------------------


type=AVC msg=audit(1207026237.006:27): avc: denied { read } for pid=2192
comm="gnome-power-man" name="ior" dev=dm-0 ino=200780
scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023
tcontext=system_u:object_r:file_t:s0 tclass=file
type=SYSCALL msg=audit(1207026237.006:27): arch=c000003e syscall=2 success=no
exit=-13 a0=16513d0 a1=0 a2=1b6 a3=7f39fab2e7b0 items=0 ppid=2173 pid=2192
auid=4294967295 uid=42 gid=42 euid=42 suid=42 fsuid=42 egid=42 sgid=42 fsgid=42
tty=(none) ses=4294967295 comm="gnome-power-man"
exe="/usr/bin/gnome-power-manager" subj=system_u:system_r:xdm_t:s0-s0:c0.c1023
key=(null)

Well the avc above reports that gnome-power-manager running as xdm_t is trying
to read a file named ior labled file_t.



-------------------------------------------------------------------------------------------------------------


Are you continuing to get the AVC after relabeling?


来自：https://bugzilla.redhat.com/show_bug.cgi?id=439726


======================================================================================
另一个回答，来自：https://bugzilla.redhat.com/show_bug.cgi?id=439726

This may be a candidate for the most misleading error message of all time!



You will get this message if gconf-sanity-check-2 tries to write a test
file into /tmp and can't read it back. It can be caused if you erase
the /tmp directory and allow the system to create a new one
automatically. It does so with the permissions set to read and execute
only, so the test file cannot be written.



Change the permissions of /tmp to 777 and it will fix it.





The command line is chmod 777 /tmp



-------------------------------------------------------------------------------------------------------------

Oldgold,



Thanks for the tip! Very interesting to learn. Agree it's good

candidate for the most misleading category.



Re: changing the permission of /tmp/:

How about

chmod a+rwxt /tmp

Nowadays /tmp/ has a "sticky bit" with it:

[timliim@taiwan ~]$ ls -ld /tmp
drwxrwxrwt. 26 root root 4096 2009-09-01 23:35 /tmp

The sticky bit on a directory (eg. /tmp/) "prevents unprivileged
users from removing or renaming a file in the directory unless
they own the file or the directory" (from "man chmod"), which is
exactly what /tmp/ needs.

Thanks!
Tim Taiwanese Liim  
-------------------------------------------------------------------------------------------------------------