From: Peter Xu <peterx@redhat.com>
To: "Chaney, Ben" <bchaney@akamai.com>
Cc: "berrange@redhat.com" <berrange@redhat.com>,
"farosas@suse.de" <farosas@suse.de>,
"armbru@redhat.com" <armbru@redhat.com>,
"mark.kanda@oracle.com" <mark.kanda@oracle.com>,
"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
"Hunt, Joshua" <johunt@akamai.com>,
"Tottenham, Max" <mtottenh@akamai.com>,
"Hudson, Nick" <nhudson@akamai.com>
Subject: Re: [PATCH] migration: cpr socket permissions fix
Date: Fri, 5 Dec 2025 10:13:19 -0500 [thread overview]
Message-ID: <aTL2j7PB4--w68ir@x1.local> (raw)
In-Reply-To: <3DD5C44B-B1D5-4E5D-95F5-45DA855DDD39@akamai.com>
On Thu, Dec 04, 2025 at 08:05:59PM +0000, Chaney, Ben wrote:
> > Considering unix socket itself doesn't really have a UID attached to it,
> > it's only the unix path that needs a chmod(), meanwhile the mgmt of course
> > knows both the right UID (as specified in -run-with) and the path, would it
> > make sense if the mgmt chmod() after it starts dest QEMU? That'll reduce
> > the scope of impact to minimum.
>
>
> I like this solution, but it runs into the issue that the main channel socket is not
> created ahead of time, so there isn't an opportunity for the management layer
> to change it's permissions. The CPR socket is created ahead of time, so we could
> use this solution there. I'm not familiar with the history here. Do you know why
> the sockets are created at different times?
IIUC the cpr channel isn't created ahead of time either, it's still created
a while after QEMU process start to run. It's just that I believe CPR
needs to synchronously wait for the client to connect first and send data,
before it can reach other part of QEMU logic to further create the main
channel.
It should look like this:
qemu_init
cpr_state_load
cpr_transfer_input
qio_net_listener_wait_client [1]
qmp_x_exit_preconfig
qmp_migrate_incoming [2]
os_setup_post
change_process_uid [3]
So IIUC you're looking for [2] creating the other unix socket.
Maybe you can stick with -incoming defer, then it'll be after step [3],
which will inherit the modified uid, and mgmt doesn't need to bother
monitoring.
Thanks,
--
Peter Xu
next prev parent reply other threads:[~2025-12-05 15:13 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-11-20 18:57 [PATCH] migration: cpr socket permissions fix Ben Chaney
2025-11-21 16:07 ` Peter Xu
2025-11-21 16:54 ` Daniel P. Berrangé
2025-12-04 20:05 ` Chaney, Ben
2025-12-05 15:13 ` Peter Xu [this message]
2025-12-08 19:32 ` Chaney, Ben
2025-12-09 18:54 ` Peter Xu
2025-12-11 18:42 ` Chaney, Ben
2025-12-11 19:12 ` Peter Xu
2025-12-11 20:44 ` Chaney, Ben
2025-12-11 21:14 ` Peter Xu
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=aTL2j7PB4--w68ir@x1.local \
--to=peterx@redhat.com \
--cc=armbru@redhat.com \
--cc=bchaney@akamai.com \
--cc=berrange@redhat.com \
--cc=farosas@suse.de \
--cc=johunt@akamai.com \
--cc=mark.kanda@oracle.com \
--cc=mtottenh@akamai.com \
--cc=nhudson@akamai.com \
--cc=qemu-devel@nongnu.org \
/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.
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 NNTP newsgroup(s).