./autorelabel

[m.roth at 5-cent.us]

Daniel J Walsh wrote:
> On 07/19/2012 11:18 AM, m.roth at 5-cent.us wrote:
>> Daniel J Walsh wrote:
>>> On 07/19/2012 11:03 AM, m.roth at 5-cent.us wrote:
>>>>
>>>> I updated a CentOS system yesterday from 6.2 to 6.3. I saw it update
>>>> selinux-policy-targeted (I think it was) and several hours later, it
>>>> still hadn't gotten to the next package; looking, it appeared to be
>>>> running a restorecon. I killed it, and redid the update.
>>>>
>>>> For other reasons, it didn't reboot. I brought it up under the most
>>>> recent previous kernel, it did an fsck on a 2T drive... then it's been
>>>> running autorelabel for at least an hour and a half, and I have no
>>>> idea how much longer it will be. It's longer than fsck.
>>>>
>>>> This is a backup server, which uses hardlinks to save space.
>>>>
>>>> You may not consider this a bug, but it certainly makes selinux close
>>>> to unusable in anything resembling a working environment.
>>>>
>>> If you have a volume with a huge number of files on it, you could mount
>>> it with a context option and this will prevent restorecon from entering
>>> the volume for relabel.  Otherwise an autorelabel will attempt to read
>>> the context on ever file on the computer and "fix" it.
<snip>
>> But still, the fact that it takes that long is what I'm griping about.
>> If I'm doing an fsck -c, to check for bad blocks, I can understand why it
>> takes forever on 2T and 3T drives; but for this, where there are some
>> significantly smaller number of files than blocks, I still see that as a
>> problem.
>
> Right when SELinux policy is updated it attempts to find the least
> possible changes of labeling between the old labeling and the new labeling
> (fixfiles -C filecontext.pre restore) In some cases this could get as
high as
> restorecon -R -v /usr or restorecon -R -v /var which seems to be what
you saw.

As a datapoint, it's now been relabelling for at least three or three and
a half hours. As I noted above, I believe that there are significantly
fewer files on this f/s than there are physical blocks that an fsck -c
would check. Therefore, I suggest to you that you folks need to revisit
your code, and look at speed optimizations.

        mark