Description of problem: We default to SELinux enabled everywhere. Having the user to pass "--selinux-relabel" to get correct labels inside the guest when using guestfs tools is counterintuitive, and may impact user experience. For example, one is more inclined to do this when creating a file inside the Guest: [Host] touch myfile [Host] virt-customize -d rhel7.9 --copy-in myfile:/etc/ But the result is an unlabeled file. [Guest] -rw-r--r--. root root system_u:object_r:unlabeled_t:s0 /etc/myfile But if one adds "--selinux-relabel", the expected outcome is achieved: [Host] virt-customize -d rhel7.9 --copy-in myfile:/etc/ --selinux-relabel [Guest]-rw-r--r--. root root system_u:object_r:etc_t:s0 /etc/myfile It is a bit unexpected that one needs to explicitly add a toggle to work with selinux. The above is just an example, but there are plenty scenarios where things break if a file inside the Guest is missing a label. Of course, --selinux-relabel is a much broader option and not every customization/sysprep needs it, so this is debatable from the technical point of view. Still, we want customers to have a good user experience and things to just work. Some ideas to improve user experience: a) Check /etc/selinux in the Guest, autodetect and relabel if necessary b) Check /etc/selinux in the Guest, autodetect and print warning if "--selinux-relabel" not given. I'd think (b) is good enough, and it would not relabel on cases where its not really needed. Version-Release number of selected component (if applicable): libguestfs-1.46.1-3.el9_0.x86_64 guestfs-tools-1.46.1-6.el9.x86_64
Hi, Germano It's a known issue in upstream: https://bugzilla.redhat.com/show_bug.cgi?id=1554735
Thanks YongkuiGuo, I'll set this one as blocked by the upstream one.
I've adjusted the upstream BZ to medium and assigned this to Rich to keep things in sync. Looks like an easy low-hanging fruit - Rich, you think we could do this to RHEL 9.1?
Let me try to fix this.
Due to how the generator works and how libguestfs-common is consumed, both fixing and testing this BZ is much more complicated than I initially thought.
[libguestfs] SELinux relabeling: do it by default Message-Id: <d5b51b1e-1489-7e53-124a-a19571518e33> https://listman.redhat.com/archives/libguestfs/2022-May/028826.html [libguestfs PATCH 0/2] generator/customize: invert SELinux relabeling default Message-Id: <20220510102757.14466-1-lersek> https://listman.redhat.com/archives/libguestfs/2022-May/028828.html [libguestfs-common PATCH 0/2] refresh generated and non-generated files related to "--selinux-relabel" Message-Id: <20220510104753.14893-1-lersek> https://listman.redhat.com/archives/libguestfs/2022-May/028831.html [guestfs-tools PATCH] adopt inversion of SELinux relabeling in virt-customize Message-Id: <20220510105046.15167-1-lersek> https://listman.redhat.com/archives/libguestfs/2022-May/028834.html [v2v PATCH] adopt inversion of SELinux relabeling in virt-customize Message-Id: <20220510105307.15402-1-lersek> https://listman.redhat.com/archives/libguestfs/2022-May/028835.html
(In reply to Laszlo Ersek from comment #7) > [libguestfs] SELinux relabeling: do it by default > Message-Id: <d5b51b1e-1489-7e53-124a-a19571518e33> > https://listman.redhat.com/archives/libguestfs/2022-May/028826.html > > [libguestfs PATCH 0/2] generator/customize: invert SELinux relabeling default > Message-Id: <20220510102757.14466-1-lersek> > https://listman.redhat.com/archives/libguestfs/2022-May/028828.html libguestfs commit range 00b9ef239342..08c4ac90f5a3 (including separate commit for common submodule update) > [libguestfs-common PATCH 0/2] refresh generated and non-generated files > related to "--selinux-relabel" > Message-Id: <20220510104753.14893-1-lersek> > https://listman.redhat.com/archives/libguestfs/2022-May/028831.html libguestfs-common commit range 81f86a0058a9..48527b8768d7 > [guestfs-tools PATCH] adopt inversion of SELinux relabeling in virt-customize > Message-Id: <20220510105046.15167-1-lersek> > https://listman.redhat.com/archives/libguestfs/2022-May/028834.html guestfs-tools commit 19de3d1c8d4e (with common submodule update squashed) > [v2v PATCH] adopt inversion of SELinux relabeling in virt-customize > Message-Id: <20220510105307.15402-1-lersek> > https://listman.redhat.com/archives/libguestfs/2022-May/028835.html virt-v2v commit 0c24fc6015ce (with common submodule update squashed)
A think a better explanation of the bug is something like this: Previously virt-customize did not default to updating SELinux permissions after making modifications to the guest filesystem. This meant that if you did not use the --selinux-relabel flag explicitly then customizations made to the guest could fail to work, for guests which use SELinux such as those running Red Hat Enterprise Linux. After this update, --selinux-relabel is now the default, so the user does not need to remember to use this flag. Guests which do not use SELinux are unaffected by this change.
Tested with guestfs-tools-1.48.1-1.el9.x86_64: Steps: 1. On RHEL9.1 host # touch testfile 2. # virt-customize -d rhel9-test --copy-in testfile:/etc [ 0.0] Examining the guest ... [ 5.6] Setting a random seed [ 5.7] Copying: testfile to /etc [ 5.7] SELinux relabelling [ 24.5] Finishing off 3. Inside the guest # ls -lZ /etc/testfile -rw-r--r--. 1 root root system_u:object_r:etc_t:s0 0 May 16 10:41 /etc/testfile The --selinux-relabel option has become a default behavior.
Verified this bug since the test case for this bug has been automated and passed in the latest nightly compose test.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory (Low: guestfs-tools security, bug fix, and enhancement update), and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHSA-2022:7959