On Mon, Apr 24, 2023 at 12:47:37PM +0200, Denis V. Lunev wrote:
> 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.
You'd still have to iterate over the filesystem for this?
> 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.
I wonder if using setfiles -T might help, see Laszlo's other reply.
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-builder quickly builds VMs from scratch
http://libguestfs.org/virt-builder.1.html
_______________________________________________
Libguestfs mailing list
Libguestfs@redhat.com
https://listman.redhat.com/mailman/listinfo/libguestfs
