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

[Rob Crittenden]

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