Re: [Libguestfs] [COMMON PATCH 0/1] mlcustomize: skip SELinux relabeling if it's disabled

On 4/24/23 10:46, Richard W.M. Jones wrote: >On Fri, Apr 21, 2023 at 09:01:40PM +0300, Andrey Drobyshev wrote: >>This patch effectively limits the number of cases when we would want to >>do a complete SELinux relabeling on Linux guest conversion. >> >>This was brought to my attention as we've recently had a support case >>when the conversion was taking too much time mostly because of >>relabeling performed with "setfiles -F". >> >>Although this patch might be worthy of taking as it is, I'd also like to >>clarify, do we really need relabeling of the entire file system during >>conversion? What exactly might go wrong here if we don't do that? >>Since this process might take hours on VMs big enough, it would be >>beneficial to be able to limit number of such cases even further, if >>possible. Unfortunately I couldn't find any hints in the libguestfs commit >>history as the relabeling code goes back to 0131d6f666 ("New tool: virt-v2v."). >Relabelling is generally needed because we may have modified or >created files during the conversion. These will not be labelled >correctly by the libguestfs appliance (as would happen when the guest >runs normally) because whatever SELinux mechanism that does this isn't >running. > >If SELinux is enforcing this can and will stop services from starting >up at boot (you will see permission errors), and can even prevent a >guest from booting at all. > >Note we don't even have a list of possible files affected because we >run stuff like dracut & rpm. > >We should probably only need to relabel over "system directories" >(whatever that means), but we currently relabel over everything >mounted (basically everything mentioned in /etc/fstab) because that's >easier. The alternate path if setfiles doesn't work touches >/.autorelabel, but that just moves the same work to boot time. > >I don't think we've seen a case of labelling taking a long time, but >it could happen. > >The patch you posted is fine because if SELinux is disabled then file >labels naturally get out of synch over time, as they won't be set on >newly created files. This is why setting SELinux to disabled isn't >really a "reversible" operation. You cannot reenable SELinux >afterwards without first doing a full filesystem relabel and reboot. >(Permissive doesn't have this problem.) > >Rich. > Would it be possible to relabel only modified files, at the first glance this should be faster.

Andrey is going to measure the performance difference and write a bit of the code. At the moment with 1 Tb image the process of relabeling taken more than 1 hour and exceed our reasonable timeout for the conversion.