[PATCH] qemu_security: Set the label of monitor

[Michal Prívozník]

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 at huawei.com>
>>> ---
>>>  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