[CentOS] SELinux and access across 'similar types'
Bennett Haselton
bennett at peacefire.org
Sun Jan 8 01:23:57 UTC 2012
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 at 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 at 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 at 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 at 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?
More information about the CentOS
mailing list