3.15. Software Collection SELinux Support

Because Software Collections are designed to install the Software Collection packages in an alternate directory, set up the necessary SELinux labels so that SELinux is aware of the alternate directory.
If the file system hierarchy of your Software Collection package imitates the file system hierarchy of the corresponding conventional package, you can run the semanage fcontext and restorecon commands to set up the SELinux labels.
For example, if the /opt/provider/software_collection_1/root/usr/ directory in your Software Collection package imitates the /usr/ directory of your conventional package, set up the SELinux labels as follows:
semanage fcontext -a -e /usr /opt/provider/software_collection_1/root/usr
restorecon -R -v /opt/provider/software_collection_1/root/usr
The commands above ensure that all directories and files in the /opt/provider/software_collection_1/root/usr/ directory are labeled by SELinux as if they were located in the /usr/ directory.

3.15.1. SELinux Support in Red Hat Enterprise Linux 7

When packaging a Software Collection for Red Hat Enterprise Linux 7, add the following commands to the %post section in the Software Collection metapackage to set up the SELinux labels:
semanage fcontext -a -e /usr /opt/provider/software_collection_1/root/usr
restorecon -R -v /opt/provider/software_collection_1/root/usr
selinuxenabled && load_policy || :
The last command ensures that the newly created SELinux policy is properly loaded, and that the files installed by a package in the Software Collection are created with the correct SELinux context. By using this command in the metapackage, you do not need to include the restorecon command in all packages in the Software Collection.
Note that the semanage fcontext command is provided by the policycoreutils-python package, therefore it is important that you include policycoreutils-python in Requires for the Software Collection metapackage.


The SELinux aspect of starting services has changed significantly in Red Hat Enterprise Linux 7. Most importantly, using the scl enable ... wrapper in a systemd service file will cause the service to be run as an unconfined process using the unconfined_service_t context. As this context has no transition rules by design, the service will not be able to transition into the target SELinux context indicated by the SELinux policy, which means scl enable ... cannot be used on Red Hat Enterprise Linux 7 if the service being started is supposed to be confined using SELinux.