I have a solution that is being installed in an enterprise environment. The solution and its deployment guide are designed to installed on a RHEL7/CentOS7 server with SELinux enabled and components being installed to locations according to the Filesystem Hierarchy Standard.
One of the clients however has surprised us by stating that all 3rd party solutions must be installed to a
/apps directory since they back this up according to policy.
To avoid deviation for this specific client, since it would require significant modifications to the solution, we decided the best approach would be to create a new directory in the
/apps directory for
/optand create symlinks upfront from the true
/opt and apply the same SELinux content to it (
ls -laZ /appl/opt drwxr-xr-x. root root unconfined_u:object_r:usr_t:s0 . drwxr-xr-x. root root unconfined_u:object_r:default_t:s0 .. drwxr-xr-x. product product unconfined_u:object_r:usr_t:s0 product la -laZ /opt drwxr-xr-x. root root system_u:object_r:usr_t:s0 . dr-xr-xr-x. root root system_u:object_r:root_t:s0 .. lrwxrwxrwx. root root unconfined_u:object_r:usr_t:s0 product -> /apps/opt/product/
Certain components of the product are accessed via Apache HTTPD and require the
httpd_sys_content_t context to be applied to them.
The files are located at
/opt/product/wwwstatic/ (which in reality is
The deployment guide specifies the following commands to run:
semanage fcontext -a -t httpd_sys_content_t "/opt/product/wwwstatic/*" restorecon -Rv /opt/product/wwwstatic
which restores the contexts on a standard installation but in this environment, because of the symlinks, it fails.
If you modify the commands to include the
/apps directory it works but deviates from a generic approach.
The contents of
# This file is auto-generated by libsemanage # Do not edit directly. /appl/opt/.* system_u:object_r:usr_t:s0 /appl/srv/.* system_u:object_r:var_t:s0 /opt/product/wwwstatic/* system_u:object_r:httpd_sys_content_t:s0
Is there a means of modifying the arguments to
restorecon commands so that this will work for symlinks (as well as normally) or have I a fundamental misunderstanding of how SELinux applies file contexts?
I believe this question differs from How do I assign an SELinux label to a symlink with semanage so it persists after a relabel? since it is about applying contexts to files in subdirectories from symlinked directories instead of applying contexts to the symlink file itself.
SELinux file contexts match based on the actual filesystem path. There is no “follow symlinks”. So your custom contexts need to reference the actual location on disk.
The standard location for third party applications is
/opt, so you are correct here. If you have a client that wants to do something nonstandard, then you should make it clear to them that they’re doing it wrong, and what the additional costs (in time and money) of that will be.
This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License.