#3534 PR open: Refactor SELinux support and enable SElinux in permissive mode in the rescue system

Labels: bug, cleanup

pcahyna opened issue at 2025-11-12 09:26:

Pull Request Details:

  • Type: Bug Fix / Cleanup

  • Impact: High

  • Reference to related issue (URL):

  • How was this pull request tested?

  • Description of the changes in this pull request:
    Refactor SELinux support to make various aspects independent and replace file-based communication between scripts by use of global variables. Also fix a bug where SELinux was enabled in enforcing mode in the rescue system, which did not work. SELinux in the rescue system is now always enabled in permissive mode (enforcing=0) when SELinux is in use on the original system.

SELinux support has multiple aspects:

  1. detecting whether SELinux is in use
  2. enabling SELinux in the rescue system
  3. adding SELinux utilities to the rescue system
  4. switching off SELinux during backup (BACKUP_SELINUX_DISABLE)
  5. detecting whether the backup program (tar, rsync) supports saving and restoring SELinux file labels
  6. forcing autorelabel after recovery

All SELinux support used to be controlled by item 4. - BACKUP_SELINUX_DISABLE - make it independent. The decision whether to disable SELinux during backup is really not related to any other aspects of SELinux handling, and I believe it is misguided and would like to remove it anyway in a follow-up. 2. (enabling SELinux in the rescue system) and 3. (adding SELinux utilities to the rescue system) now depends purely on 1. Item 5. (SELinux save/restore by the backup program) is independent, as the tools are able to backup and restore SELinux labels just fine even if SELinux is not enabled (I tested this).

The decision of 6. (forcing autorelabel after recovery) now depends on the outcome of 5. (whether labels are backed up and restored). To preserve compatibility for now, autorelabel is still enforced by a separate script when BACKUP_SELINUX_DISABLE is set (the default) - see issue #1957. I plan to change this aspect in the future.

Introduce a new variable BACKUP_PROG_SELINUX that allows the user to indicate whether the NETFS backup program (if neither tar nor rsync) supports SELinux label backup and restore, as for custom backup programs we have no way to detect this.

For this PR, I am experimenting with code generation by Claude Code, which also wrote most of the commit messages (therefore they are quite verbose and don't follow my usual style). The refactoring plan was created by me and I supervised the tool and reviewed the results in detail.

jsmeix commented at 2025-11-12 13:13:

@pcahyna
thank you for such major overhauling and cleanup work.
I appreciate it very much because rather often
there is only time for "duct tape" fixes.

jsmeix commented at 2025-11-12 13:32:

I had a quick first look and I noticed:

(1)
adding SELinux utilities to the rescue system
happens via PROGS and not via REQUIRED_PROGS.
Is this intentional? If yes, why?
I think, when it was autodetected or specified
that SELinux should be used, then its programs
are required to be in the ReaR recovery system.

(2)
The link
usr/share/rear/prep/YUM/default/200_selinux_in_use.sh
-> ../../RSYNC/GNU/Linux/200_selinux_in_use.sh
is removed but there is still the user config variable
YUM_BACKUP_SELINUX_CONTEXTS
Is the BACKUP=YUM code OK with the changes in this pull request
or would the BACKUP=YUM code need adaptions?
In general regarding BACKUP=YUM cf.
https://github.com/rear/rear/issues/3428#issuecomment-3350712028
so if the BACKUP=YUM code needs difficult adaptions
we may simply declare it unsupported right now
if YUM_BACKUP_SELINUX_CONTEXTS is not 'no' and
Error out in this case so the user is informed
(of course this would be not very friendly
but still better than to blindly proceed knowingly
that YUM_BACKUP_SELINUX_CONTEXTS='yes' is unsupported).

pcahyna commented at 2025-11-12 14:03:

adding SELinux utilities to the rescue system
happens via PROGS and not via REQUIRED_PROGS.
Is this intentional? If yes, why?
I think, when it was autodetected or specified
that SELinux should be used, then its programs
are required to be in the ReaR recovery system.

It is in PROGS because the utilities are not actually used for anything (yet) so they are added only because the admin might need them if SELinux is in use (and if SELinux is not in use, they don't get added in order to save space in the ramdisk - Claude Code convinced me to do this).

pcahyna commented at 2025-11-12 14:05:

Regarding YUM: I will check what the variable does, but IIRC it saves the contexts entirely independently of the script under RSYNC and thus the symlink is not needed. In any case, the script now handles only rsync and YUM does not use rsync (it has tar hardcoded), so the script would not do anything useful even if the symlink existed.

pcahyna commented at 2025-11-12 14:07:

@jsmeix IIRC SLES now uses SELinux as well - can you test the change on SLES, please? Ideally with BACKUP_SELINUX_DISABLE=0.

jsmeix commented at 2025-11-12 14:37:

@pcahyna
yes, I know that SLES also uses SELinux
in particular the new SLES 16 uses it by default,
see "Transition to SELinux" in
https://www.suse.com/c/what-is-new-in-suse-linux-enterprise-server-16-0/

Nevertheless I have no experience with SELinux.
I have no experience with most of what there is in Linux.
For most of what there is in Linux I am just a user,
e.g. kernel, glibc, X11/Wayland, browser, audio/video,...

As time permits I will have a look regarding
testing ReaR on SLES with SELinux enabled.
But don't wait for me.
Feel free to mercilessly overhaul and cleanup things
right now as you think what seems to be best.

[Export of Github issue for rear/rear.]