On Tue, Mar 11, 2025 at 11:44:57PM +0100, Stefano Brivio wrote: > On Tue, 11 Mar 2025 12:35:46 +1100 > David Gibson wrote: > > > On Fri, Mar 07, 2025 at 11:41:20PM +0100, Stefano Brivio wrote: > > > It might not be feasible for users to start passt-repair after passt > > > is started, on a migration target, but before the migration process > > > starts. > > > > > > For instance, with libvirt, the guest domain (and, hence, passt) is > > > started on the target as part of the migration process. At least for > > > the moment being, there's no hook a libvirt user (including KubeVirt) > > > can use to start passt-repair before the migration starts. > > > > > > Add a directory watch using inotify: if PATH is a directory, instead > > > of connecting to it, we'll watch for a .repair socket file to appear > > > in it, and then attempt to connect to that socket. > > > > So, with this change, running > > passt-repair /tmp > > > > would be a Bad Idea. > > ...why? On any distribution where it's available, you can make it > connect to whatever you want, and it will do nothing else than > returning an error when passt tries to switch a socket to repair > mode. I mean that if you are able to run it privileged, then it would be a bad idea to do so with /tmp as the watch directory. Since that's kind of the default place to point it, it's a footgun. > It will just work in the KubeVirt use case we planned for, for the > moment. > > Then sure, you can give it capabilities or run it as root, disable > LSMs, and make it connect to whatever process. But you need root > anyway, so there isn't much to be gained. > > > But that is the default path used by passt. To > > use this safely, you really want to have a directory set aside for the > > use of just one passt instance, or at least passt-owning uid. > > Right, that's what happens if libvirt starts it. > > > I feel like we should enforce, or at least document and encourage that > > somewhere. Not really sure where, though, so, with some misgivings > > I think we'll find a more reasonable solution by the time this becomes > actually usable by mere mortals using distribution packages. I would > anyway drop all this once we figure out how to make it convenient for > libvirt. For stand-alone usage, this is not really needed. Hm. I guess we'll see. -- David Gibson (he or they) | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you, not the other way | around. http://www.ozlabs.org/~dgibson