On Tue, Mar 11, 2025 at 11:44:57PM +0100, Stefano Brivio wrote:On Tue, 11 Mar 2025 12:35:46 +1100 David Gibson <david(a)gibson.dropbear.id.au> wrote: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.On Fri, Mar 07, 2025 at 11:41:20PM +0100, Stefano Brivio wrote:...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.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.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.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/~dgibsonBut 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 misgivingsI 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.