A daemon on a RHEL host is refused access to a file that it owns and that is mode 0644, and `chmod 777` on the file changes nothing. Which access-control layer is denying it, and how does a process's domain and a file's type produce that decision?

## Two gates, in order A Linux file access passes through discretionary access control (DAC) first: the kernel compares the calling process's UID/GID against the file's owner, group and mode bits, plus any POSIX ACL. Only if that succeeds does the request reach the Linux Security Module hooks where SELinux makes its own decision. Mandatory access control (MAC) can therefore only ever *subtract* access — it never grants something the mode bits refused. This ordering explains the symptom completely. If a `chmod 777` makes no difference, the failing check was never the mode bits, because they were already passing. Recognising that is the whole point of the question: the candidate who reaches for `chmod` a second time has not understood that there are two independent gates. ## Domains, types and the security context SELinux attaches a *security context* to every subject and object. Written out, it has four fields: ``` system_u:object_r:httpd_sys_content_t:s0 user : role : type :level ``` Under the `targeted` policy that RHEL and Fedora ship, the field that carries almost all of the weight is the **type**. A type applied to a process is conventionally called a *domain*; a type applied to a file, socket or port is just a type. The user and role fields matter mainly for confined user logins, and the level field carries MCS categories used to keep otherwise-identical instances apart. The policy is a compiled set of rules of the shape "allow *source domain* *target type*:*object class* { *permissions* }". A read of a file by the web server is a question about `httpd_t` reading `httpd_sys_content_t:file`. If such a rule exists, the access proceeds; if not, it is denied. Nothing about the file's owner or mode enters into that decision. Inspect both sides with the `-Z` flag that the coreutils and procps tools carry: ```bash ls -Z /srv/www/index.html ps -eZ | grep httpd id -Z ``` ## Where a label comes from A file's type is stored on the inode, in the `security.selinux` extended attribute, so it travels with the file rather than with its path string. New files normally inherit a type from the directory they are created in, subject to the policy's transition rules — which is why content dropped into `/srv/www` by an unpacking script may end up as `default_t` or, if it came from a user's home directory with `mv`, keeps whatever it had there. A process's domain comes from an *entrypoint transition*: when a confined parent executes a binary whose file type is an entrypoint for a domain, the new process starts in that domain instead of inheriting the parent's. That is how a service launched by the init system ends up in its own confined domain rather than running unconfined. ## Reading the denial The kernel records the refusal as an AVC message in the audit log. The fields to read are `scontext` (who was asking), `tcontext` (what they asked about), `tclass` (the object class — file, dir, tcp_socket, and so on) and the permission in braces. Those four items usually tell you immediately whether the *file* is mislabelled or the *policy* genuinely does not cover what the application is trying to do. The application itself sees only `EACCES` and typically logs "permission denied", so its own logs will not mention SELinux at all. ## "Even root is confined" — with a caveat Mandatory access control is mandatory in the sense that the object's owner cannot relax it: a process running as UID 0 inside a confined domain is bound by the same rules as any other process in that domain, which is the containment value of the whole system. The honest caveat is that under the targeted policy an administrator's interactive shell normally runs as `unconfined_t`, a domain the policy allows almost everything, so root at a login shell is in practice not confined. Saying that nuance out loud is what distinguishes someone who has run the system from someone who has read a summary of it. ## Fixing it properly The fix depends on which side is wrong. If the file's type is wrong for where it lives, restore it from the policy's default-context database. If the type is right but the policy genuinely does not allow the access, look for an existing tunable before writing anything new. What you should never do is widen the mode bits, move the data somewhere with looser labelling, or switch the machine out of enforcing — all three trade a real containment boundary for a symptom that stops being visible.