Stop fighting SELinux by blindly running restorecon

Technical Briefing | 11/6/2026

Every time someone hits an EACCES error, the immediate reflex is to spam restorecon or flip the boolean to permissive mode. I get it. You have a deploy deadline and your app needs to write to that directory. But treating security labels as something to reset when they get in your way is how you end up with a gaping hole in your sandbox that some attacker will eventually walk right through.

Why your labels keep drifting

The underlying issue usually isn’t that SELinux is broken, it’s that you moved files manually or your CI pipeline created them with the wrong context. When you cp a file, it keeps the original context. When you mv it, it carries the old one. Neither of these actions invokes the automatic relabeling that a touch or mkdir would trigger. This is the silent killer of policy compliance.

semanage fcontext -a -t httpd_sys_rw_content_t '/var/www/html/uploads(/.*)?' && restorecon -Rv /var/www/html/uploads

• Never use -R on restorecon unless you actually audited the entire directory tree first
• Check /etc/selinux/targeted/contexts/files/file_contexts.local to see what overrides are actually active
• Always test changes with matchpathcon before applying them to production paths

If you are still seeing denials after verifying the file context, stop guessing and start reading the actual audit trail. ausearch -m avc -ts recent is your best friend here. It will show you exactly which domain is being blocked and which target context it is fighting with. Don’t disable the policy. Adjust the context using semanage, apply it, and verify that the AVC denial stops appearing in your logs.

Spend ten minutes learning how the policy transit rules work instead of just masking the symptoms. Next time you have a weird file system permission issue, check the labels first. If you fix the context rather than the chmod, your future self will thank you when the auditors come calling.