file contexts labelling - possible bug?

[Matthew Ife]

This might just be me being daft in some sense but I have come across
the following situation and was hoping someone could shed light on it.

Part of setting up kerberos involves creating a principal database with
the kdb5_util command.

When you setup the database (typically as unconfined_t on a default
installation) it puts various files in;
/var/kerberos/krb5kdc
of which include the principal database itself and various controls such
as a lock file.

This folder gets the context krb5kdc_conf_t and a few file contexts
exist in the fcontext database to manage the additional creation of
files in side, one of which is the principal.ok file which is used as a
lock file.

When creating the lock file with the command above it should get the
label (according to fcontexts) of krb5kdc_lock_t as a regex exists such
as:
/var/kerberos/krb5kdc/principal.*\.ok		system_u:object_r:krb5kdc_lock_t

But, the file gets the parent directory context of conf_t. Likewise,
removing the lock file manually and touching the file again also
demonstrates the same behavior. If you then run restorecon/fixfiles on
the directory it will correctly reset the file to the right location.

I've checked with strace to see if something strange happens (if the
principal.ok file gets created as a temp name then moved) but there is
no such behaviour. Thus I'm stuck in understanding whats going on. Why
does default filesystem labelling give the file conf_t and restorecon
give it the (correct) lock_t?