shouldn't selinux::fcontext do the necessary exec_restorecon ?

[dvanders]

Normally when we persist an fcontext change we need to also use restorecon to apply the change [1].
It can happen that users are unaware of this requirement, and expect that the selinux::fcontext alone is sufficient.
So, I propose that we either document this minor annoyance in the list of known issues/limitations or, better, add an optional feature to selinux::fcontext to manage the implied selinux::exec_restorecon.

E.g. I'm proposing that it should be sufficient to do:

selinux::fcontext { '/var/www/usage':
  seltype  => 'httpd_sys_content_t',
}

but users currently need to do:

selinux::fcontext { '/var/www/usage':
  seltype  => 'httpd_sys_content_t',
}
~> selinux::exec_restorecon { '/var/www/usage': }

Thanks!

[1] https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/selinux_users_and_administrators_guide/sect-security-enhanced_linux-working_with_selinux-selinux_contexts_labeling_files#sect-Security-Enhanced_Linux-SELinux_Contexts_Labeling_Files-Persistent_Changes_semanage_fcontext

[ekohl]

A parameter exec_restorecon_on_change (or similar) makes sense to me. Just for compatibility with previous versions I'm leaning to defaulting to false. An additional reason to do it inside the define is that you can nicely encapsulate the behavior.

Could you come up with a patch for this?

[bschonec]

I've been struggling with this same problem for the last two days. Only today did I realize that exec_restorecon needs to be invoked in code in order for the context to be applied. At the very least, the README.md should be updated.