All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Anthony Harivel" <aharivel@redhat.com>
To: "Paolo Bonzini" <pbonzini@redhat.com>,
	"Daniel P. Berrangé" <berrange@redhat.com>
Cc: <mtosatti@redhat.com>, <qemu-devel@nongnu.org>, <vchundur@redhat.com>
Subject: Re: [PATCH v3 2/3] tools: build qemu-vmsr-helper
Date: Fri, 01 Mar 2024 12:08:49 +0100	[thread overview]
Message-ID: <CZID7GHAWHXR.2UTDU0T1RHPX4@fedora> (raw)
In-Reply-To: <CABgObfaRGL8eOs6NRBjEMjTa_7UGyAn+Pic2GP=XbE+Qg-oBCQ@mail.gmail.com>

Hi Paolo,

> > > +static void compute_default_paths(void)
> > > +{
> > > +    socket_path = g_build_filename("/run", "qemu-vmsr-helper.sock", NULL);
> > > +    pidfile = g_build_filename("/run", "qemu-vmsr-helper.pid", NULL);
> > > +}
> >
> > We shouldn't be hardcoding /run, we need to honour --prefix and
> > --localstatedir args given to configure.  /var/run is a symlink
> > to /run so the end result ends up the same AFAIK
>
> Indeed; just copy from scsi/qemu-pr-helper.c.
>

When I copy the same as compute-default() of scsi/qemu-pr-helper.c, the 
helper is listening to "/var/local/run/qemu-vmsr-helper.sock".

Problem is /var/local/run is 700 while /run is 755.

So I would need to adjust the qemu-vmsr-helper.service to give 
the --socket=PATH of qemu-vmsr-helper.socket (i.e 
 /run/qemu-vmsr-helper.sock)

Problem is when I do that , I fall into the case: 
"Unix socket can't be set when using socket activation"

So I'm a bit confused what to do about that.

> > You never answered my question from the previous posting of this
> >
> > This check is merely validating the the thread ID in the message
> > is a child of the process ID connected to the socket. Any process
> > on the entire host can satisfy this requirement.
> >
> > I don't see what is limiting this to only QEMU as claimed by the
> > commit message, unless you're expecting the UNIX socket permissions
> > to be such that only processes under the qemu:qemu user:group pair
> > can access to the socket ? That would be a libvirt based permissions
> > assumption though.
>
> Yes, this is why the systemd socket uses 600, like
> contrib/systemd/qemu-pr-helper.socket. The socket can be passed via
> SCM_RIGHTS by libvirt, or its permissions can be changed (e.g. 660 and
> root:kvm would make sense on a Debian system), or a separate helper
> can be started by libvirt.
>
> Either way, the policy is left to the user rather than embedding it in
> the provided systemd unit.
>

During this patch test, when I run by hand my VM (without libvirt),
the vmsr helper systemd service/socket was like that: 
[Service]
ExecStart=/usr/bin/qemu-vmsr-helper
User=root
Group=root

and 

[Socket]
ListenStream=/run/qemu-vmsr-helper.sock
SocketUser=qemu
SocketGroup=qemu
SocketMode=0660

And it seems to works. So I'm not sure 100% what to do in my patch.

Should I follow the pr-helper systemd files anyway ?

Regards,
Anthony



  parent reply	other threads:[~2024-03-01 11:09 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-01-25  7:22 [PATCH v3 0/3] Add support for the RAPL MSRs series Anthony Harivel
2024-01-25  7:22 ` [PATCH v3 1/3] qio: add support for SO_PEERCRED for socket channel Anthony Harivel
2024-01-25 16:37   ` Daniel P. Berrangé
2024-01-29 19:25     ` Paolo Bonzini
2024-01-29 19:30       ` Daniel P. Berrangé
2024-01-25  7:22 ` [PATCH v3 2/3] tools: build qemu-vmsr-helper Anthony Harivel
2024-01-29 18:53   ` Daniel P. Berrangé
2024-01-29 19:33     ` Paolo Bonzini
2024-01-29 19:45       ` Daniel P. Berrangé
2024-01-29 19:53         ` Daniel P. Berrangé
2024-01-29 20:21           ` Paolo Bonzini
2024-02-21 13:19         ` Anthony Harivel
2024-02-21 13:47           ` Daniel P. Berrangé
2024-02-21 13:52             ` Anthony Harivel
2024-03-01 11:08       ` Anthony Harivel [this message]
2024-01-25  7:22 ` [PATCH v3 3/3] Add support for RAPL MSRs in KVM/Qemu Anthony Harivel
2024-01-29 19:29   ` Daniel P. Berrangé
2024-02-20 14:00     ` Anthony Harivel
2024-02-20 15:00       ` Daniel P. Berrangé
2024-03-05 14:58     ` Anthony Harivel
2024-01-30  9:13   ` Daniel P. Berrangé
2024-03-04 14:41     ` Anthony Harivel
2024-03-04 14:48       ` Daniel P. Berrangé
2024-03-05 13:25         ` Anthony Harivel
2024-03-05 13:57           ` Daniel P. Berrangé
2024-01-30  9:39   ` Daniel P. Berrangé
2024-03-12 11:21     ` Anthony Harivel
2024-03-12 15:49       ` Daniel P. Berrangé
2024-03-13 10:48         ` Anthony Harivel
2024-03-13 11:04           ` Daniel P. Berrangé
2024-03-14  8:26             ` Anthony Harivel
2024-03-14  8:55               ` Daniel P. Berrangé

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=CZID7GHAWHXR.2UTDU0T1RHPX4@fedora \
    --to=aharivel@redhat.com \
    --cc=berrange@redhat.com \
    --cc=mtosatti@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=vchundur@redhat.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.