On 9/6/2021 9:21 PM, Michal Prívozník wrote: > On 9/6/21 2:36 PM, Peng Liang wrote: >> Signed-off-by: Peng Liang <liangpeng10@xxxxxxxxxx> >> --- >> src/qemu/qemu_security.c | 6 ++++++ >> 1 file changed, 6 insertions(+) >> >> diff --git a/src/qemu/qemu_security.c b/src/qemu/qemu_security.c >> index 19d957dd4b96..96755a62bd2c 100644 >> --- a/src/qemu/qemu_security.c >> +++ b/src/qemu/qemu_security.c >> @@ -52,6 +52,12 @@ qemuSecuritySetAllLabel(virQEMUDriver *driver, >> priv->chardevStdioLogd, >> migrated) < 0) >> goto cleanup; >> + if (priv->monConfig && >> + virSecurityManagerSetChardevLabel(driver->securityManager, >> + vm->def, >> + priv->monConfig, >> + priv->chardevStdioLogd) < 0) >> + goto cleanup; >> >> if (virSecurityManagerTransactionCommit(driver->securityManager, >> pid, priv->rememberOwner) < 0) >> > > Is there a specific bug that you are trying to solve?Not a functional bug. Just when using qemu to run QEMU process, I found that the socket of monitor will not be changed to qemu:qemu while other sockets (e.g. the socket of qemu agent) will. > If so then it > should be recorded in the commit message. But anyway - libvirt shouldn't > have any difficulties connecting to the socket. The "setXXXLabel" > functions are meant to grant access to QEMU and in the case of monitor > it's actually QEMU who creates the socket.If QEMU support to accept fd for chardev, then libvirt (not QEMU) will create and pass the fd to QEMU. > Having said that, whatever > this patch tries to solve doesn't feel right. > > Michal > > . > Thanks, Peng
