Exercise 2: A "Permissions Error" That Isn't Actually a Permissions Problem — Possible Solution ==================================================================== THE LIKELY REAL CAUSE ------------------------------ Per this chapter's own warn-box, "a service failing with what looks like a permissions error, despite chmod/chown already being correct, is a classic Fedora/RHEL troubleshooting trap - the real cause is very often an SELinux policy denial... not a file-permission problem at all." Since file ownership and mode bits are confirmed correct, the next most likely explanation, per this chapter, is that SELinux - "enabled and set to Enforcing by default on Fedora and RHEL" - is denying the access at its own separate policy layer, independent of whatever standard Unix permissions already allow. WHY THIS CAN HAPPEN EVEN WITH CORRECT UNIX PERMISSIONS ------------------------------ Per this chapter, "a service can have entirely correct standard Unix file permissions and still be denied access, because SELinux enforces an additional, separate policy layer on top of ordinary permissions." SELinux doesn't replace or duplicate the standard permission check - it adds a second, independent check on top of it, meaning passing the first (Unix permissions) doesn't guarantee passing the second (SELinux policy) at all. HOW TO CONFIRM IT ------------------------------ Per this chapter's own tip-box, "sestatus confirms whether SELinux is active and in Enforcing or Permissive mode; ausearch -m avc -ts recent searches the audit log directly for recent denials." Running these would confirm directly whether SELinux is active and whether it has actually logged a denial matching the service's own attempted access, rather than continuing to assume a Unix-permissions cause that's already been ruled out. WHY DISABLING SELINUX ISN'T THE RIGHT FIX ------------------------------ Per this chapter, "disabling SELinux entirely to make the error go away is a real, meaningful security regression, not a fix - the correct response is adjusting the SELinux policy (or the file's own security context) to permit the specific access actually needed." Turning SELinux off removes an entire, deliberately designed security layer system-wide just to resolve one specific access issue, when the correct fix is narrowly permitting only the specific access the service genuinely needs, leaving the rest of SELinux's own protection intact. WHY THIS WORKS AS AN ANSWER ------------------------------ It identifies SELinux as the likely real cause using this chapter's own warn-box, explains why correct Unix permissions don't guarantee passing SELinux's own separate check, names the specific diagnostic commands, and explains precisely why disabling SELinux trades away broad protection rather than fixing the actual, narrow problem.