On Thu, Apr 18, 2024 at 06:29:53PM +0100, Daniel P. Berrangé wrote: > On Wed, Mar 20, 2024 at 09:10:48AM -0700, Andrea Bolognani wrote: > > On Wed, Mar 20, 2024 at 10:18:39AM -0400, Stefan Berger wrote: > > > On 3/20/24 08:23, Peter Krempa wrote: > > > > Did you consider the case when the migration fails and the VM will be > > > > restored to run on the source host again? In such case doin the > > > > relabelling might break the source host. > > > > > > Right. I seem to remember testing such scenarios. I had to put an exit() (or > > > something like it) into swtpm on the destination side to trigger the > > > fallback to the source side. The swtpm on the source side had closed file > > > access and wants to open them (lockfile) again and so the files needed to be > > > labeled correctly if the storage on the source side is > > > on the disk and exported via NFS from there (iirc). If the storage is > > > NFS-exported from a 3rd host it probably would not require the labels. > > > > I didn't really consider the failure scenario, so thank you for > > bringing that up. > > > > I think it would be still fine. If the source has NFS storage, then > > access will keep working regardless of what relabeling the > > destination has been up to in the meantime. And if the source has > > local storage, then the relabeling on the destination (via NFS) will > > not actually have touched the SELinux labels. > > > > The only concern I have is that, when going from local to NFS, labels > > might have been restored on the source side. But I assume that > > restoring only happens once the migration has been confirmed as > > successful? I'll check. > > > > Once again, as far as I can tell (please let me know if I'm wrong!) > > there is no special casing when it comes to disks and other types of > > persistent storage, so if this approach was problematic I would have > > expected many issues to have been reported by now. > > The Labelling and shared filesystems combination has some major > caveats. > > By default NFS doesn't enable use of SELinux labels, so if both > sides are on NFS, a generic label will be used for everything on > the NFS volume and everything will be fine. > > If you enable use of labelling on NFS though, you can no longer > use dynamic label assignment. static label assignment must be > used, so ensure the same SELinux label is used on both sides of > the migration. This is because both QEMU's need to be able to > open the shared files, even if only 1 is actively writing. In > this case we don't need to relabel the files on the shared FS, > but it is a no-op if we try. > > If one side is ext4 and the other side is NFS, then the same > applies if NFS has labelling enabled. > > If one side is ext4 and the other side is NFS, without labelling > enabled, then I think we're probably in a world of hurt. Can you please point me to documentation on how to enable SELinux for NFS? Based on what I found I *think* you need NFS v4.2, but I'm pretty sure I'm currently using that (how to make sure?) and I'm still seeing nfs_t for everything on the client side. Given the lack of information around this, I'm still not entirely convinced that SELinux can be made to work at all over NFS. But you're right that dynamic label assignment can't really work in general over shared filesystems, and the only reason we currently get away with it is that NFS and most (all?) other shared filesystems don't do SELinux. Mixing ext4 and NFS the way these patches allow you to do doesn't make the situation any worse or better in that regard. -- Andrea Bolognani / Red Hat / Virtualization _______________________________________________ Devel mailing list -- devel@xxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxx
