You clear an SELinux denial by running `chcon -t httpd_sys_content_t` on a data directory and the service starts working; weeks later, after the machine is relabelled, it breaks again. Where do SELinux file labels live, and what should you have done instead?

## Two places a label can be said to live It helps to separate the *actual* label from the *expected* label. The actual label is on the object: an extended attribute called `security.selinux` on the inode, which `ls -Z` prints and which travels with the file across renames and hard links because it belongs to the inode, not to the name. The expected label is in the policy: a database of regular expressions mapping pathnames to default contexts, shipped by the policy package and extended by the administrator. On a targeted-policy system it is compiled from the file-contexts rules under `/etc/selinux/targeted/contexts/files/`. Nothing consults this database at access time — the kernel only ever looks at the actual label. The database exists so the system can *recompute* correct labels on demand. ## What each tool does `chcon` writes the actual label and touches nothing else. It is the SELinux equivalent of `chmod`: an immediate, unexplained change to one object. `restorecon` does the opposite: it reads the expected label out of the database and writes it onto the object, discarding whatever was there. `restorecon -Rv` walks a tree and reports every change; `restorecon -n -v` previews without writing, which is the safe way to find out what a relabel would do before you run it. `semanage fcontext` edits the database itself. `semanage fcontext -a -t <type> "<regex>"` adds a local rule; `-l` lists them, `-d` deletes one. Local rules are stored separately from the policy's shipped rules and survive policy package updates. So the sequence in the question is now obvious: `chcon` changed the object, the database still disagreed, and the first thing to relabel that path — an explicit `restorecon`, a package update touching the tree, or a boot-time `/.autorelabel` — resolved the disagreement in the database's favour. ```bash # durable: teach the policy, then apply it semanage fcontext -a -t httpd_sys_content_t "/srv/data(/.*)?" restorecon -Rv /srv/data ``` Note the regex form. `semanage fcontext` takes a regular expression, not a glob, and `(/.*)?` is the idiom meaning "this directory and everything under it". Anchoring it wrongly is the usual way this step silently does nothing. ## Why files arrive mislabelled in the first place The most common cause is moving data instead of copying it. `mv` preserves the inode and therefore preserves the extended attribute, so a file relocated from a home directory into a service's data directory keeps its home-directory type and the service cannot read it. A plain `cp` creates a new inode, which gets a label derived from the destination and the policy's transition rules — usually the right one. `cp -a` or `cp --preserve=context` deliberately carries the source label across, which reintroduces the same problem. Other routine causes: unpacking an archive that restores stored attributes, restoring from a backup taken on a differently-labelled system, or creating a service's data directory in a location the policy has no rule for at all, which lands it in a generic default type. ## When a path genuinely has no correct type If you have relocated a service's data to a non-standard path, there may be no shipped rule that covers it. Two clean options exist. Either add the `semanage fcontext` rule as above, mapping your path to the type the policy already knows about, or use `semanage fcontext -a -e /var/www /srv/www` to declare the new path *equivalent* to the standard one, so every rule that applies under the original applies under yours. The equivalency form is preferable when the tree contains several different types under it, because it inherits the whole set rather than flattening everything to one type. ## What good practice looks like Use `chcon` to test a hypothesis quickly, confirm the service recovers, then immediately convert the finding into a `semanage fcontext` rule plus a `restorecon`, and put that pair into whatever configuration management builds the host. Verify by running `restorecon -n -v` over the tree and seeing no proposed changes — that is the check that your fix is actually durable. If you ever find yourself scripting `chcon` in a cron job or a service start-up hook to keep labels correct, that is a sign the database rule is missing.