// learn · linux · rhcsa · 8 min

SELinux contexts, animated.

Every file and every process on a SELinux-enforcing system carries a security context. Watch how the policy engine compares them — and why a misplaced file is the most common cause of production-day denials.

// SELinux contexts

SELinux is mandatory access control. Beyond regular ugo permissions, every process and every object gets a label, and policy decides what label can touch what. Confusing at first; elegant once it clicks.

// before you start

you should know

·Basic Linux file permissions (chmod, chown)
·Running services with systemctl
·Reading log files (tail, grep, less)

by the end you'll

Explain how SELinux blocks or allows an access, and run the three commands that fix 99% of denials in production.

pace: 8 minutes

selinux contexts — step 1 / 6 · actors + contexts

Every actor carries a context

SELinux (Security-Enhanced Linux) is an extra layer of access control built into RHEL-family systems. It works by giving every running program AND every file on disk a label — called a 'context'. When one tries to touch the other, the kernel checks both labels against a policy that says what's allowed. Below: the Apache web server (httpd) and a file it wants to read — both have contexts.

// key insight

When a service mysteriously fails on RHEL — works on dev, breaks in prod — SELinux is the first thing to suspect. The fix is almost never "disable SELinux"; it's usually a wrong label or a missing boolean. Learn the troubleshooting flow and you'll save hours.

// exam-ready commands

$ls -Z fileshow file context

$ps -eZ | grep httpdshow process context

$id -Zyour shell's context

$chcon -t TYPE_t filemanually set a type (temporary)

$restorecon -v filereset to policy default

$semanage fcontext -a -t TYPE_t '/path(/.*)?'make a relabel permanent

$ausearch -m AVC -ts recentrecent SELinux denials

$audit2why -altranslate denials to human

$getsebool -a | grep httpdpolicy switches for a service

$setsebool -P bool ontoggle a boolean persistently

// check yourself

4 quick questions

Which field of a SELinux context matters most for everyday decisions?

Apache can read /var/www/html on a fresh install but breaks after you copy a file there from /home. Most likely cause?

Which command resets a file's context to whatever the policy says it should be?

Where does the kernel log SELinux denials?

These aren't graded — they're just for active recall, which is what actually makes the lesson stick.

Read this lesson as text6 chapters · quiz answers

01Every actor carries a context
SELinux (Security-Enhanced Linux) is an extra layer of access control built into RHEL-family systems. It works by giving every running program AND every file on disk a label — called a 'context'. When one tries to touch the other, the kernel checks both labels against a policy that says what's allowed. Below: the Apache web server (httpd) and a file it wants to read — both have contexts.
02Anatomy of a context — four fields
A context has four colon-separated parts. For everyday decisions, only the third field (the TYPE, which always ends in _t) matters. The other three (user, role, sensitivity level) are for advanced setups you usually won't touch.
03Policy decides: can httpd read this file?
When httpd tries to read the file, the kernel asks the SELinux policy: 'does a process of type httpd_t have permission to read a file of type httpd_sys_content_t?' Policy says yes — access is granted. This is called 'type enforcement' and it's how 99% of SELinux decisions get made.
04Wrong label = denial
Now imagine you copied the file from your home directory. It kept its old context: user_home_t. The policy now asks: 'can httpd_t read user_home_t?' Answer: no. The read is blocked and the kernel writes a denial record (called an AVC — Access Vector Cache) to /var/log/audit/audit.log. From the app's point of view it just looks like permission denied.
05Fix it with restorecon
restorecon is the everyday fix. It looks at where the file lives (in this case /var/www/html) and resets the file's context to whatever the SELinux policy says belongs there. There's also chcon for a manual one-off override — but a future restorecon will overwrite your chcon change. Use chcon for experiments; use restorecon for the real fix.
06Troubleshooting workflow — three commands
When a service mysteriously fails on a SELinux-enforcing system: (1) check the audit log for denials with ausearch -m AVC -ts recent; (2) feed those denials to audit2why -al, which translates the cryptic record into plain English and usually tells you exactly what to fix; (3) apply the fix — restorecon for a wrong label, setsebool for a policy switch (called a 'boolean').

Quiz — answers

Which field of a SELinux context matters most for everyday decisions?: →type (e.g. httpd_t, always ends in _t)Type enforcement is the dominant mechanism. The other fields are for advanced multi-level or multi-category setups.
Apache can read /var/www/html on a fresh install but breaks after you copy a file there from /home. Most likely cause?: →The copied file kept its home-directory context (user_home_t) and Apache can't read that typeCopy operations sometimes preserve the source context. restorecon /var/www/html (or restorecon -Rv) fixes it.
Which command resets a file's context to whatever the policy says it should be?: →restorecon -v /pathrestorecon consults the policy and applies the canonical label. chcon is just a manual override.
Where does the kernel log SELinux denials?: →/var/log/audit/audit.logAVC denials are written by auditd to /var/log/audit/audit.log. Use ausearch or audit2why to read them.

// more in linux

keep going — these pair well with what you just learned.

see all linux →

⚡

Linux boot process

From power button to login prompt. Every stage in the chain — UEFI, GRUB, kernel, initramfs, systemd — with the rescue moves that save you. RHCSA-ready.

9 min · interactiveopen →

💾