A service that runs fine on an Ubuntu host fails with permission denied after being deployed onto a Red Hat Enterprise Linux host, even though file ownership and mode bits are identical on both machines. What about RHEL's default configuration explains this, and how do you confirm it before changing anything?

## Two access checks, not one On a traditional Unix system, an access decision comes from discretionary access control: the file's owner, group and mode bits, evaluated against the process's credentials. Discretionary means the owner of the object decides — if you own a file, you may open its permissions to everyone. Mandatory access control adds a second, independent check that the object's owner cannot waive. The kernel consults a system-wide policy, and the operation proceeds only if *both* checks pass. SELinux is the mandatory access control implementation RHEL ships, and the important fact for this question is the default: enforcing mode with the targeted policy, from a stock installation, with no action from the administrator. That is why identical ownership and identical mode bits produce different outcomes on the two hosts. The mode bits are not the whole decision on RHEL. ## Why Ubuntu did not warn you Debian and Ubuntu also ship a mandatory access control system — AppArmor — enabled by default. The difference is coverage and philosophy. AppArmor's shipped profiles confine a specific set of packaged programs; a service you built and installed yourself typically has no profile and runs unconfined. RHEL's targeted policy also aims at a set of confined domains rather than every process, but the surrounding policy governs far more of the system, and the labelling applied to files and ports means an unpackaged service can still find itself denied by policy that was written about the *resources* rather than about the program. The honest framing in an interview is: the platform did not become stricter by accident. RHEL is frequently chosen *because* of this posture — it is the reason a security team signed off on the platform, and often the reason a compliance profile is satisfiable at all. Treating it as an obstacle to switch off is the answer that ends the interview. ## Confirming the diagnosis Work in this order, and change nothing until the first two steps are done. 1. **Establish the mode.** `getenforce` reports `Enforcing`, `Permissive` or `Disabled`. If it says Enforcing, mandatory access control is a live suspect. If it says Permissive, denials are logged but not applied — so it is *not* your cause, and you should look elsewhere. 2. **Look for the denial.** Enforcement decisions that refuse an operation are logged as denial records by the audit subsystem. Reproduce the failure and look at the audit log for entries written at that instant; the record names the process, the operation and the target, and its presence is direct evidence rather than inference. 3. **Prove causation if you still need to.** Temporarily switch to permissive with `setenforce 0`, retry the operation, and switch back with `setenforce 1` immediately. If the operation succeeds in permissive and fails in enforcing, you have your answer. This is a diagnostic step measured in seconds, not a configuration change — a host left permissive is a host that quietly lost the property it was chosen for. Note that `setenforce` is a runtime toggle only; it does not survive a reboot, which is a useful safety property when you are experimenting on someone else's server. ## The patterns that trigger it during a migration Without going into how policy is written, these are the shapes of change that reliably produce a denial on RHEL and nothing at all on a stock Ubuntu box: - Application data placed under a non-standard directory — an application root somewhere convenient rather than where the policy expects that kind of content to live. - Files moved into place rather than created there, or unpacked from an archive built on another system, so they arrive carrying the wrong classification. - A daemon listening on an unusual port number. - A service reaching outside its expected footprint — writing where it normally only reads, or opening a network connection when nothing it normally does requires one. Recognising the *shape* is the senior skill here: you can predict during planning which parts of a migration will need policy attention, rather than discovering them one production incident at a time. ## The fixes, ranked The correct resolution is to bring the deployment into line with policy, or to extend policy deliberately for this workload. Both are ordinary, supported operations with their own tooling. What is not acceptable, in an interview or in production: - Widening file permissions until the error goes away. It does not address a policy denial at all, and it leaves a genuine permissions defect behind — you have weakened one control while the other still refuses. - Disabling enforcement globally so the deployment can proceed. On a platform picked for its security posture, this converts a fixable packaging problem into an audit finding, and it will be discovered by someone other than you. - Assuming the RHEL host is misconfigured. It is at its defaults; the Ubuntu host was the permissive one. Build the policy work into the migration plan as a known workstream, and the surprise stops being a surprise.