When working with Apache and SELinux, we often encounter a specific challenge with symbolic links. While the target directory (/srv/www in this case) may have the correct httpd_sys_content_t context, the symlink itself at /var/www gets labeled with var_t. This creates permission issues despite the target being properly labeled.
The usual approaches fail here:
# Temporary fix with chcon
chcon -h -t httpd_sys_content_t /var/www
This works until the next filesystem relabel. Similarly:
# Standard semanage approach that misses the symlink
semanage fcontext -a -t httpd_sys_content_t "/var/www(/.*)?"
Only affects the target, not the symlink itself.
To permanently label the symlink itself, we need to:
# First verify the current file context
matchpathcon -V /var/www
# Add the symlink-specific context
semanage fcontext -a -f l -t httpd_sys_content_t /var/www
# Apply the new policy
restorecon -v /var/www
The critical flag is -f l which specifies we're dealing with a symbolic link (type 'l' as seen in ls -l output).
After implementation:
ls -lZ /var/www
# Should show:
# lrwxrwxrwx. root root system_u:object_r:httpd_sys_content_t:s0 www -> /srv/www
# Test with Apache
curl -I localhost
# Should return HTTP 200 rather than 403 Forbidden
For systems with many symlinks, consider creating a custom policy module:
# Generate a local policy
cat > my_apache_symlink.te <- Always test changes in a staging environment first
- The solution persists across reboots and relabels
- Consider security implications of allowing symlink traversal
- Document these changes in your configuration management system
When working with SELinux on Linux systems, symbolic links often present a unique challenge for context labeling. The issue becomes particularly apparent in web server configurations where the DocumentRoot is a symlink pointing to another location.
$ ls -lZ /var/www
lrwxrwxrwx. root root unconfined_u:object_r:var_t:s0 www -> /srv/www
While the target directory (/srv/www) might have the correct context (httpd_sys_content_t), the symlink itself inherits var_t from the /var directory. This can cause problems even though the target has proper permissions.
The immediate solution using chcon seems to work initially:
$ sudo chcon -h -t httpd_sys_content_t /var/www
$ ls -lZ /var/www
lrwxrwxrwx. root root unconfined_u:object_r:httpd_sys_content_t:s0 www -> /srv/www
However, this change won't survive a system relabel operation:
$ sudo restorecon -Rv /var/www
restorecon reset /var/www context system_u:object_r:httpd_sys_content_t:s0->system_u:object_r:var_t:s0
The standard method of using semanage fcontext doesn't directly solve this problem because it affects the target rather than the symlink itself:
$ sudo semanage fcontext -a -t httpd_sys_content_t "/var/www(/.*)?"
$ sudo restorecon -Rv /var/www
This will properly label files within the target directory but leaves the symlink context unchanged.
To make the context change permanent for the symlink itself, we need to use a combination of tools:
$ sudo semanage fcontext -a -f -l -t httpd_sys_content_t "/var/www"
$ sudo restorecon -v /var/www
The key options here are:
-f -l: Specifies we're dealing with a symbolic link- The path is specified without wildcards to target the link itself
After applying these changes, verify with:
$ ls -Zd /var/www
lrwxrwxrwx. root root system_u:object_r:httpd_sys_content_t:s0 /var/www -> /srv/www
And test that it survives a relabel:
$ sudo touch /.autorelabel
$ sudo reboot
# After reboot
$ ls -Zd /var/www
For systems where you can't modify the policy, you can use:
$ sudo chcon -h -t httpd_sys_content_t /var/www
$ sudo restorecon --no-target-normalize -v /var/www
This prevents restorecon from resetting the symlink's context while still processing other files normally.
When implementing this solution:
- Ensure your policy actually allows httpd to traverse symlinks (check with
getsebool -a | grep httpd) - Remember that the symlink's context primarily affects operations on the link itself (like renaming or deleting)
- For maximum security, consider restructuring your setup to avoid symlinks in critical paths