[Freeipa-users] krb5-server-1.9-33.el6_3.3.x86_64 prevents named from starting when selinux is enforcing

Sigbjorn Lie sigbjorn at nixtra.com
Fri Sep 21 17:52:01 UTC 2012


On 09/21/2012 02:47 PM, Rob Crittenden wrote:
> Simo Sorce wrote:
>> ----- Original Message -----
>>> Sigbjorn Lie wrote:
>>>> On 09/20/2012 10:17 PM, Rob Crittenden wrote:
>>>>> bind isn't my strongest suite.
>>>>>
>>>>> My guess is that this file is the ccache for bind. I'm guessing
>>>>> that
>>>>> 25 is the UID of the named user. If this is the case, then it
>>>>> should
>>>>> be safe to stop named, rename the file, and restart. Perhaps the
>>>>> contexts have changed so when this gets re-created it will get
>>>>> fixed
>>>>> automagically.
>>>>>
>>>>> rob
>>>>>
>>>> You guessed well!! :)
>>>>
>>>> Stop named:
>>>> # service named stop
>>>>
>>>> Enable selinux:
>>>> # setenforce 1
>>>>
>>>> Verify that error still exists:
>>>> # service named start
>>>> Starting named: [FAILED]
>>>>
>>>> Rename file:
>>>> # cd /var/tmp
>>>> # mv DNS_25 DNS_25_old
>>>>
>>>> Attempt to start named again:
>>>> # service named start
>>>> Starting named: [  OK  ]
>>>>
>>>> Voila!
>>>>
>>>> A before and after shot:
>>>> # ls -lZ DNS_25*
>>>> -rw-------. named named unconfined_u:object_r:named_tmp_t:s0 DNS_25
>>>> -rw-------. named named system_u:object_r:tmp_t:s0 DNS_25_old
>>>>
>>>> What's the odds that this was the entire issue and that named will
>>>> now
>>>> keep running safe and sound?
>>>>
>>>
>>> Hard to say. Because restorecon didn't fix the bad context I suspect
>>> this isn't directly covered in policy. So if the file should get the
>>> wrong context again you could be back in this position. It is
>>> probably
>>> worth filing a bug. I'm not entirely sure whether it should be
>>> against
>>> bind or selinux, but it'll get to the right folks either way
>>> eventually.
>>
>> That file is the reply-cache, and it's context is set at runtime by the
>> krb5 library. It did get out of sync because selinux was disabled, and
>> restorecon, can't fix the label because the file is in a tmp directory,
>> so it just takes the tmp_t context by default.
>>
>> If selinux is not completely disable this shouldn't happen anymore, 
>> however,
>> should it happen you can simply remove the file, it is not vital and 
>> will
>> get recreated after you restart named.
>>
>> Simo.
>>
>
> AFAIK he never disabled SELinux. He put it into permissive temporarily 
> to get going again while we diagnosed this but before and after the 
> krb5-server upgrade he was in enforcing mode.
>
> I wonder if the krb5-server upgrade caused a filesystem relabel and 
> this is what hosed the /var/tmp entry.
>
> rob

This is my test environment, and I disabled SElinux completely after the 
upgrade to 2.2 as I got annoyed with how slow it was. The "yum upgrade" 
occured while SElinux was in disabled mode. I then set selinux=enforcing 
in /etc/sysconfig/selinux and rebooted after yum upgrade completed. I 
then set SElinux to permissive during the troubleshooting we did a few 
days ago.

My production environment still got SElinux set to enforcing, and the 
krb5-server has not yet been upgraded until these issues has been clarified.

I'm sorry for the confusion.

Is the conclusion that I'm having this issue in the first place because 
SElinux was disabled when I did "yum upgrade" ?




Regards,
Siggi




More information about the Freeipa-users mailing list