[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [RFC Patch 0/3] Accept passed in socket 'fd' open from
Re: [Qemu-devel] [RFC Patch 0/3] Accept passed in socket 'fd' open from outside for unix socket
Thu, 2 Jun 2016 00:16:59 +0800
Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0
On 2016年06月01日 00:44, Daniel P. Berrange wrote:
ah.. adjusting permission or file location can solve this problem, i'm
guessing maybe this is a more security concern, the socket is used as a
network interface for a vm, similar as the qcow image file, thus should
prevent it to be arbitrarily accessed.
On Wed, Jun 01, 2016 at 12:30:44AM +0800, address@hidden wrote:
From: Wei Xu <address@hidden>
Recently I'm working on a fd passing issue, selinux forbids qemu to
create a unix socket for a chardev when managing VMs with libvirt,
because qemu don't have sufficient permissions in this case, and
proposal from libvirt team is opening the 'fd' in libvirt and merely
passing it to qemu.
This sounds like a bug in libvirt, or selinux, or a mistaken configuration
of the guest. It is entirely possible for QEMU to create a unix socket - not
least because that is exactly what QEMU uses for its QMP monitor backend.
Looking at your example command line, I think the issue is simply that you
should be putting the sockets in a different location. ie at
/var/lib/libvirt/qemu/$guest-vhost-user1.sock where QEMU has permission to
create sockets already.
Michael, do you have any comment on this?
Currently i just add it for unix socket, and the connect/listen syscall
must have a path name, an inet socket doesn't need this param at all,
should it be supported also?
Alternatively you could enhance the SELinux policy to grant svirt_t the
permission to create sockets under /var/run/openvswitch too.
I finished a RFC patch for Unix socket after a glance of the code,
and not sure if this is right or there maybe other side-effects,
please point me out.
I tested it for both server and client mode 'PF_UNIX' socket with a VM
Old command line:
New command line:
because unix socket is bundled with a path, so it should be kept even with the
'fd' is indicated, this looks odd, any comments?
Yes, this syntax doesn't really make sense. The passed in sockfd may not
even be a UNIX socket - it could be a TCP socket. As such, the 'sockfd'
option should be mutually exclusive with the 'path' and 'host' options.
ie you can only supply one out of 'sockfd', 'path', or 'host'.
OK, thanks for you quick feedback, i just wonder if 'add-fd' and
qemu_open() can be a more general solution.
FWIW, I think the ability to pass a pre-opened socket FD with the
-chardev socket backend is a useful enhancement, even though I don't
think you need this in order to fix the problem you have.