Question
SELinux security context mismatches after rsync file-level restore on Fedora 38
Mira Orbit
0 reputation · 23 Mar 2022, 12:06 UTC
131.7K views1
Loading…
0 reputation · 23 Mar 2022, 12:06 UTC
An rsync restore on Fedora 38 may complete with a zero exit code while the restored files lose their original SELinux security contexts, leading to access denials for applications under enforcing mode. The exit status only confirms that the transfer finished, not that the written bytes match the source data, and standard rsync options do not guarantee context preservation.
Verification therefore requires separate checksum comparison and SELinux label restoration, but running sha256sum -c on large restored trees can be I/O intensive, and the effectiveness of restorecon depends on the active policy and path type.
What method can reliably verify that restored files retain their original SELinux contexts, and which post‑restore verification technique ensures data integrity with minimal additional read operations?
35775 reputation · 23 Mar 2022, 17:00 UTC
Verify SELinux contexts with matchpathcon or a recursive dry-run restorecon -R -v -n before restoring application access. For data integrity, compare size and mtime with stat or find first, then run sha256sum only on files whose metadata differs. An rsync exit code of 0 confirms transfer completion only.
Standard rsync does not preserve SELinux security contexts unless it runs as root with -X/--xattrs on a destination filesystem that supports extended attributes. Restored files usually inherit the target directory's default context or the creating process's context, which can cause access denials under enforcing mode.
fedoramatchpathcon /restored/path displays the expected default context from the active policy without modifying files.restorecon -R -v -n /restored/path lists recursive label mismatches as a dry run and writes nothing.restorecon applies default policy labels and may not reproduce custom or non-default source contexts.sha256sum -c is I/O intensive; metadata pre-filtering limits additional reads.getenforce. If SELinux is disabled, label mismatches are hidden and not enforced.matchpathcon /restored/path output with current labels from ls -Z /restored/path.restorecon -R -v -n /restored/path to preview files that would be relabeled.restorecon -R /restored/path, then re-check with matchpathcon and ls -Z.stat or find.sha256sum only on metadata-mismatched files and compare against source checksums.Did rsync run with -X/--xattrs as root on an xattr-capable filesystem? If yes, source contexts may have been preserved and still require verification. If no, contexts were not copied and restorecon is the appropriate remediation.
Assumptions: behavior reflects Fedora 38 rsync and SELinux tooling versions; results may differ on other releases. Context checks are meaningful only while SELinux is enabled.
Use comments to ask for clarification. Post a solution as an answer.
6,300 reputation · 23 Mar 2022, 17:23 UTC
A key distinction: restorecon -n -R -v checks files against the active policy, not the original backup contexts. If the targeted policy was updated between backup and restore (common on Fedora 38), files correctly labeled per the old policy will be flagged as mismatches even though rsync -aX preserved the xattrs faithfully.
To verify the transfer preserved contexts without reading file contents, sample critical paths with:
getfattr -n security.selinux /src/etc/httpd/conf/httpd.conf /dst/etc/httpd/conf/httpd.confFor data integrity with minimal I/O on RPM-owned trees, rpm -Va --nomtime --nosize --nomode --nordev --nolinkto --nouser --nogroup --nocaps --nodigest /restored/path uses cached RPM metadata rather than re-reading files. This covers /etc, /usr, and packaged /var content but excludes user data in /home, /srv, or /var/lib.
Combine both: restorecon dry-run for policy alignment, getfattr spot-checks for xattr fidelity, rpm -Va for packaged content digests.