Bug 2213385

I was not able to reproduce this on my setup.

Please attach the full debug log of virtqemud as well as the full VM xml used.

There is nothing that changed in libvirt between the releases where it supposedly works and where it doesn't, but the error message in qemu was added recently [1].

Note that the FD is passed down from python via libvirt to qemu.

Libvirt invokes the following commands:
2023-06-26 01:46:37.056+0000: 1846131: info : qemuMonitorSend:864 : QEMU_MONITOR_SEND_MSG: mon=0x7fd41c0d6460 msg={"execute":"getfd","arguments":{"fdname":"graphicsfd"},"id":"libvirt-12"} fd=24
2023-06-26 01:46:37.058+0000: 1846153: debug : qemuMonitorJSONIOProcessLine:191 : Line [{"return": {}, "id": "libvirt-12"}]
2023-06-26 01:46:37.058+0000: 1846131: info : qemuMonitorSend:864 : QEMU_MONITOR_SEND_MSG: mon=0x7fd41c0d6460 msg={"execute":"add_client","arguments":{"protocol":"vnc","fdname":"graphicsfd","skipauth":false},"id":"libvirt-13"} fd=-1
2023-06-26 01:46:37.060+0000: 1846153: debug : qemuMonitorJSONIOProcessLine:191 : Line [{"id": "libvirt-13", "error": {"class": "GenericError", "desc": "parameter @fdname must name a socket"}}]

and then attempts to clean up:

2023-06-26 01:46:37.061+0000: 1846131: info : qemuMonitorSend:864 : QEMU_MONITOR_SEND_MSG: mon=0x7fd41c0d6460 msg={"execute":"closefd","arguments":{"fdname":"graphicsfd"},"id":"libvirt-14"} fd=-1
2023-06-26 01:46:37.062+0000: 1846153: info : qemuMonitorJSONIOProcessLine:210 : QEMU_MONITOR_RECV_REPLY: mon=0x7fd41c0d6460 reply={"id": "libvirt-14", "error": {"class": "GenericError", "desc": "File descriptor named 'graphicsfd' not found"}


[1]:
commit bf5de8c5d66552721fefe08de849c115ca366b56
Author: Marc-André Lureau <marcandre.lureau>
Date:   Mon Mar 6 16:27:45 2023 +0400

    qmp: 'add_client' actually expects sockets
    
    Whether it is SPICE, VNC, D-Bus, or the socket chardev, they all
    actually expect a socket kind or will fail in different ways at runtime.
    
    Throw an error early if the given 'add_client' fd is not a socket, and
    close it to avoid leaks.
    
    This allows to replace the close() call with a more correct & portable
    closesocket() version.
    
    (this will allow importing sockets on Windows with a specialized command
    in the following patch, while keeping the remaining monitor associated
    sockets/add_client code & usage untouched)
    
    Signed-off-by: Marc-André Lureau <marcandre.lureau>
    Reviewed-by: Philippe Mathieu-Daudé <philmd>
    Acked-by: Markus Armbruster <armbru>
    Message-Id: <20230306122751.2355515-6-marcandre.lureau>


As noted I can't reproduce this with upstream qemu with the above python code.

Moving to qemu for further analysis.

That looks like `getsockopt(fd, SOL_SOCKET, SO_TYPE)` failed. The code treat any error (including ENOTSOCK) as indicating fd is not a socket.

Maybe SELinux is preventing calling getsockopt?

@lcheng
Could you check and attach the audit log, and  with selinux disabled? 

thanks

Thanks very much. Test with 'setenforce 0', no error to call openGraphics().


# setenforce 0
# getenforce 
Permissive

# python
Python 3.9.17 (main, Jun 26 2023, 00:00:00) 
[GCC 11.4.1 20230605 (Red Hat 11.4.1-2)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import libvirt
>>> import socket
>>> server, client = socket.socketpair(socket.AF_UNIX, socket.SOCK_STREAM)
>>> conn = libvirt.open()
>>> domobj = conn.lookupByName("vm1")
>>> domobj.openGraphics(0, server.fileno(), 0)
0

thanks, moving to selinux-policy for further analysis.

Could you update the policy to allow qemu `getsockopt(fd, SOL_SOCKET, SO_TYPE)` ?

Hi, 

Can you please reproduce the issue in permissive mode with full auditing enabled?


1) Open the /etc/audit/rules.d/audit.rules file in an editor.
2) Remove the following line if it exists:
-a task,never
3) Add the following line to the end of the file:
-w /etc/shadow -p w
4) Restart the audit daemon:
  # service auditd restart
5) Re-run your scenario.
6) Collect AVC denials:
  # ausearch -i -m avc,user_avc,selinux_err,user_selinux_err -ts today

Thank you,
Nikola

Hi Nikola,

I followed the steps in comment 9 to reproduce the issue. AVC denials as follows:

# ausearch -i -m avc,user_avc,selinux_err,user_selinux_err -ts today
----
type=PROCTITLE msg=audit(08/11/2023 02:58:15.735:37112) : proctitle=/usr/libexec/qemu-kvm -name guest=vm1,debug-threads=on -S -object {"qom-type":"secret","id":"masterKey0","format":"raw","file":" 
type=SYSCALL msg=audit(08/11/2023 02:58:15.735:37112) : arch=x86_64 syscall=getsockopt success=no exit=EACCES(Permission denied) a0=0x72 a1=SOL_SOCKET a2=SO_TYPE a3=0x7f4f73528f44 items=0 ppid=1 pid=489494 auid=unset uid=qemu gid=qemu euid=qemu suid=qemu fsuid=qemu egid=qemu sgid=qemu fsgid=qemu tty=(none) ses=unset comm=qemu-kvm exe=/usr/libexec/qemu-kvm subj=system_u:system_r:svirt_t:s0:c94,c660 key=(null) 
type=AVC msg=audit(08/11/2023 02:58:15.735:37112) : avc:  denied  { getopt } for  pid=489494 comm=qemu-kvm scontext=system_u:system_r:svirt_t:s0:c94,c660 tcontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tclass=unix_stream_socket permissive=0


# rpm -q qemu-kvm selinux-policy
qemu-kvm-8.0.0-10.el9.x86_64
selinux-policy-38.1.17-1.el9.noarch


Thank you,
lcheng

Issue migration from Bugzilla to Jira is in process at this time. This will be the last message in Jira copied from the Bugzilla bug.

This BZ has been automatically migrated to the issues.redhat.com Red Hat Issue Tracker. All future work related to this report will be managed there.

To find the migrated issue, look in the "Links" section for a direct link to the new issue location. The issue key will have an icon of 2 footprints next to it, and begin with "RHEL-" followed by an integer.  You can also find this issue by visiting https://issues.redhat.com/issues/?jql= and searching the "Bugzilla Bug" field for this BZ's number, e.g. a search like:

"Bugzilla Bug" = 1234567

In the event you have trouble locating or viewing this issue, you can file an issue by sending mail to rh-issues.