On 9/6/2021 10:52 PM, Michal Prívozník wrote: > On 9/6/21 4:33 PM, Peng Liang wrote: >> 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. > > So the only QEMU version that we currently support and doesn't have FD > passing is 2.11.0. The FD passing was implemented in 2.12.0. > I don't think it's worth the trouble and also I think this way it's a > bit safer since a regular user can't go beyond libvirt's back and > connect to the monitor directly. While we do have qemu-monitor-command > it is going to log the arguments so sysadmin at least knows what > commands were executed. > > At any rate, this is not the correct place. That would be where the > socket is created (qemuBuildChrChardevStr) but then again, I don't think > it's worth the trouble. > > Michal > > . > OK, I'll drop this patch. Thanks, Peng
