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
25 is the UID of the named user. If this is the case, then it
be safe to stop named, rename the file, and restart. Perhaps the
contexts have changed so when this gets re-created it will get


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  ]


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
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
worth filing a bug. I'm not entirely sure whether it should be
bind or selinux, but it'll get to the right folks either way

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.


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.


Freeipa-users mailing list

Reply via email to