I asked this question after a simple error on my part with SELinux. It has a 'user mapping' section. I added myself as a user. Picking up the defaults it added me as a SELinux user of type user_u. No ill effects noticed I shut the machine down for the day. Yesterday, when I booted up, I tried to clear out the emacs backup files... and realised I couldn't due to permissions problems. Ah well, su then delete them as root. No. Never heard of su I was told by bash. Oh shhhugar. Log out, log in as root? Nope. (That was down to FC10, more later). So I posted the question on the Fedora Forum list. 'dgrift' answered within the hour and correctly diagnosed the problem and offered an appropriate solution. C-M-F2 takes me to a new terminal (as does ssh root@localhost I found out). So that's how to get into root when SELinux is telling you to bog off. That was resolved using (as root)

/usr/sbin/semanage login -m -s unconfined_u -r s0-s0:c0.c1023 dpawson

which seemingly converts my SELinux 'self' from user_u to unconfined_u.. which means I can access su and delete my own files! Doesn't seem to be a lot to ask?

Note, I had to reboot for that to take effect though.

The more direct solution; disable SELinux. Do this (again as root), by editing /etc/selinux/config, Change the line which sets the 'mode' for selinux to SELINUX=disabled, where it currently has SELINUX=permissive. This kicks SELinux into touch.

I really don't want tools getting in the way. I like *nix tools. They are helpful. No way do I want a tool operating that is hindering me working.

The other problem, not being able to log in as root at the graphical login screen; I resolved that by changing /etc/pam.d/gdm, where I Replaced auth required pam_succeed_if.so user != root quiet with auth required pam_succeed_if.so

Problems solved. Just half a day wasted with SELinux. Now documented, I'll know where to look next time. If the security wonks at Fedora want to play with security, let them use their own machines, not ours. Once they have a working system, wrap it in user friendly interface and I'm sure I and others will welcome it! Currently screens such as the one below are no bloody help at all.

SELinux is preventing access to files with the default label, default_t. 
Detailed Description
[SELinux is in permissive mode, the operation would have been denied but was permitted due to permissive mode.]

SELinux permission checks on files labeled default_t are being
denied. These files/directories have the default label on them. This
can indicate a labeling problem, especially if the files being
referred to are not top level directories. Any files/directories under
standard system directories, /usr, /var. /dev, /tmp, ..., should not
be labeled with the default label. The default label is for
files/directories which do not have a label on a parent directory. So
if you create a new directory in / you might legitimately get this
label. Allowing AccessIf you want a confined domain to use these files
you will probably need to relabel the file/directory with chcon. In
some cases it is just easier to relabel the system, to relabel
execute: "touch /.autorelabel; reboot"

Additional Information

Source Context:  system_u:system_r:httpd_t:s0
Target Context:  system_u:object_r:default_t:s0
Target Objects:  ./index.php [ file ]
Source:  httpd
Source Path:  /usr/sbin/httpd
Port:  <Unknown>
Host:  marge
Source RPM Packages:  httpd-2.2.10-2
Target RPM Packages:  Policy RPM:  selinux-policy-3.5.13-26.fc10
Selinux Enabled:  True
Policy Type:  targeted
MLS Enabled:  True
Enforcing Mode:  Permissive
Plugin Name:  default
Host Name:  marge
Platform:  Linux marge 2.6.27.5-117.fc10.i686 #1 SMP Tue Nov 18 12:19:59 EST 2008 i686 i686
Alert Count:  1
First Seen:  Mon 08 Dec 2008 03:46:19 PM GMT
Last Seen:  Mon 08 Dec 2008 03:46:19 PM GMT
Local ID:  2c928e87-4f32-4aa4-8688-9517c688a8a2
Line Numbers:  

Raw Audit Messages :
node=marge type=AVC msg=audit(1228751179.13:68):
avc: denied { read } for pid=2693 comm="httpd" name="index.php"
dev=sda2 ino=17449099 scontext=system_u:system_r:httpd_t:s0
tcontext=system_u:object_r:default_t:s0 tclass=file 

node=marge type=SYSCALL msg=audit(1228751179.13:68): arch=40000003
syscall=5 success=yes exit=16 a0=b9653478 a1=0 a2=1b6 a3=b9653478
items=0 ppid=2685 pid=2693 auid=4294967295 uid=48 gid=48 euid=48
suid=48 fsuid=48 egid=48 sgid=48 fsgid=48 tty=(none) ses=4294967295
comm="httpd" exe="/usr/sbin/httpd" subj=system_u:system_r:httpd_t:s0
key=(null)

Now isn't that informative! Some actually do provide information to enable me to stop the 'error' (course it's my fault!) happening again. The one above? Haven't a clue

Hope this might help others disable SELinux