On 1/7/2012 9:58 AM, John R. Dennison wrote: > On Sat, Jan 07, 2012 at 09:09:45AM -0800, Bennett Haselton wrote: >> OK, I followed the instructions at >> http://wiki.centos.org/HowTos/SELinux >> for re-labeling the filesystem and it did not work. Why not? Since you >> said you had "no issues" figuring it out. > It "did not work" _how_? How did it fail? What was on the console > during the relabel? > > I've never had a relabel fail. YMMV. > I've posted several messages about this, but to sum up the current state of the problem: This is a remotely hosted machine so I don't know what's coming up on the console. But ls -lZ reports several files of type "file_t", such as: [root@g6950-21025 ~]# ls -lZ /tmp/hostname_SKYSLICE.INFO -rw-r--r-- apache apache system_u:object_r:file_t /tmp/hostname_SKYSLICE.INFO sealert says that a file_t filetype means the relabel failed: >>> Summary: SELinux is preventing access to files with the label, file_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 file_t are being denied. file_t is the context the SELinux kernel gives to files that do not have a label. This indicates a serious labeling problem. No files on an SELinux box should ever be labeled file_t. If you have just added a new disk drive to the system you can relabel it using the restorecon command. Otherwise you should relabel the entire files system. Allowing Access: You can execute the following command as root to relabel your computer system: "touch /.autorelabel; reboot" >>> So, I ran the "touch /.autorelabel; reboot" commands but that didn't fix it. Then I read at http://wiki.centos.org/HowTos/SELinux that sometimes this isn't enough if the machine has been upgraded from an old CentOS version, so I ran # genhomedircon # touch /.autorelabel # reboot but that still didn't fix it as I still get: [root@g6950-21025 ~]# ls -lZ /tmp/hostname_SKYSLICE.INFO -rw-r--r-- apache apache system_u:object_r:file_t /tmp/hostname_SKYSLICE.INFO Daniel suggested running "fixfiles restore", which I did, and got this output: >>> [root@g6950-21025 ~]# fixfiles restore /sbin/setfiles: labeling files under / ******************************************************************************* ***********************matchpathcon_filespec_eval: hash table stats: 98376 elements, 30515/65536 buckets used, longest chain length 18 /sbin/setfiles: labeling files under /var/tmp matchpathcon_filespec_eval: hash table stats: 2 elements, 2/65536 buckets used, longest chain length 1 /sbin/setfiles: labeling files under /tmp matchpathcon_filespec_eval: hash table stats: 19 elements, 19/65536 buckets used, longest chain length 1 /sbin/setfiles: labeling files under /boot matchpathcon_filespec_eval: hash table stats: 44 elements, 44/65536 buckets used, longest chain length 1 /sbin/setfiles: Done. >>> and I rebooted for good measure, but I still get: [root@g6950-21025 ~]# ls -lZ /tmp/hostname_SKYSLICE.INFO -rw-r--r-- apache apache system_u:object_r:file_t /tmp/hostname_SKYSLICE.INFO Any ideas? _______________________________________________ CentOS mailing list CentOS@xxxxxxxxxx http://lists.centos.org/mailman/listinfo/centos