SELinux: Fixing Dovecot Mail Spool Context (/var/vmail)¶
If Dovecot is generating SELinux AVC denials and mail delivery or retrieval is broken on a Fedora/RHEL system with SELinux enforcing, the /var/vmail directory tree likely has incorrect file contexts.
Symptoms¶
- Thousands of AVC denials in
/var/log/audit/audit.logfor Dovecot processes - Denials reference
var_tcontext on files under/var/vmail/ - Mail delivery may fail silently; IMAP folders may appear empty or inaccessible
ausearch -m avc -ts recentshows denials like:
Why It Happens¶
SELinux requires files to have the correct security context for the process that accesses them. When Postfix/Dovecot are installed on a fresh system and /var/vmail is created manually (or by the mail stack installer), the directory may inherit the default var_t context from /var/ rather than the mail-specific mail_spool_t context Dovecot expects.
The correct context for the entire /var/vmail tree is mail_spool_t — including the tmp/ subdirectories inside each Maildir folder.
Do NOT apply dovecot_tmp_t to Maildir tmp/ directories
dovecot_tmp_t is for Dovecot's own process-level temp files, not for Maildir tmp/ folders. Postfix's virtual delivery agent writes to tmp/ when delivering new mail. Applying dovecot_tmp_t will block Postfix from delivering any mail, silently deferring all messages with Permission denied.
Fix¶
1. Check Current Context¶
If you see var_t instead of mail_spool_t, the contexts need to be set. If you see dovecot_tmp_t on tmp/, that needs to be corrected too.
2. Define the Correct File Context Rule¶
One rule covers everything — including tmp/:
If you previously added a dovecot_tmp_t rule for tmp/ directories, remove it:
# Check for an erroneous dovecot_tmp_t rule
sudo semanage fcontext -l | grep vmail
# If you see one like "/var/vmail(/.*)*/tmp(/.*)?" with dovecot_tmp_t, delete it:
sudo semanage fcontext -d "/var/vmail(/.*)*/tmp(/.*)?"
3. Apply the Labels¶
This relabels all existing files. On a mail server with many users and messages, this may take a moment and will print every relabeled path.
4. Verify¶
Both should show mail_spool_t:
system_u:object_r:mail_spool_t:s0 /var/vmail/
system_u:object_r:mail_spool_t:s0 /var/vmail/example.com/user/tmp/
5. Flush Deferred Mail¶
If mail was queued while the context was wrong, flush it:
6. Check That Denials Stopped¶
No output = no new denials.
Variant: a Freshly-Rebuilt Box Left in Permissive Mode¶
If a server was rebuilt or migrated and came up Permissive (check getenforce), the symptom flips: mail works fine, but /var/log/audit/audit.log quietly fills with thousands of dovecot_t → var_t denials that would break IMAP/LMTP the instant you switch to Enforcing. The mailstore was created or rsync'd onto /var/vmail with no fcontext rule, so it defaulted to var_t.
Apply the relabel above first, then flip to Enforcing only after verifying zero new denials:
MARK=$(date +%H:%M:%S)
# ...deliver a test message + do an IMAP login...
ausearch -m avc -ts "$MARK" | grep -c denied # expect 0
setenforce 1
sed -i 's/^SELINUX=permissive/SELINUX=enforcing/' /etc/selinux/config
Companion denial: a Postfix virtual-mailbox server that looks up recipients in MySQL also trips postfix_cleanup_t reading /etc/my.cnf* (mysqld_etc_t). Allow it with a small local module:
See also Inbound Spam Filtering — the SpamAssassin Bayes DB belongs under /var/lib/spamassassin (spamd_var_lib_t) for the same labeling reason.
Key Notes¶
- One rule is enough —
"/var/vmail(/.*)?"withmail_spool_tcovers every file and directory under/var/vmail, including alltmp/subdirectories. semanage fcontextis persistent — the rules survive reboots andrestoreconcalls. You only need to runsemanageonce.restoreconapplies current rules to existing files — run it after anysemanagechange and any time you manually create directories.- New mail directories are labeled automatically — SELinux applies the registered
semanagerules to any new files created under/var/vmail. var_tcontext is the default for/var/— any directory created under/var/without a specificsemanagerule will inheritvar_t. This is almost never correct for service data directories.