public inbox for passt-dev@passt.top
 help / color / mirror / code / Atom feed
From: Stefano Brivio <sbrivio@redhat.com>
To: David Gibson <david@gibson.dropbear.id.au>
Cc: passt-dev@passt.top
Subject: Re: [PATCH] passt-repair: Add directory watch
Date: Tue, 11 Mar 2025 23:44:57 +0100	[thread overview]
Message-ID: <20250311234457.4986a498@elisabeth> (raw)
In-Reply-To: <Z8-TcptFZA8REhbS@zatzit>

On Tue, 11 Mar 2025 12:35:46 +1100
David Gibson <david@gibson.dropbear.id.au> 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.

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.

-- 
Stefano


  reply	other threads:[~2025-03-11 22:45 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-03-07 22:41 [PATCH] passt-repair: Add directory watch Stefano Brivio
2025-03-11  1:35 ` David Gibson
2025-03-11 22:44   ` Stefano Brivio [this message]
2025-03-12  0:31     ` David Gibson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20250311234457.4986a498@elisabeth \
    --to=sbrivio@redhat.com \
    --cc=david@gibson.dropbear.id.au \
    --cc=passt-dev@passt.top \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://passt.top/passt

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for IMAP folder(s).