On 09.06.2016 11:16, Daniel P. Berrange wrote: > On Wed, Jun 08, 2016 at 05:48:57PM -0400, Aaron Conole wrote: >> Flavio Leitner <f...@redhat.com> writes: >> >>> Adding Aaron who is fixing exactly that on the OVS side. >>> >>> Aaron, please see the last question in the bottom of this email. >>> >>> On Wed, Jun 08, 2016 at 06:07:29AM -0400, Amnon Ilan wrote: >>>> >>>> >>>> ----- Original Message ----- >>>>> From: "Michal Privoznik" <mpriv...@redhat.com> >>>>> To: "Daniel P. Berrange" <berra...@redhat.com> >>>>> Cc: qemu-devel@nongnu.org, "amit shah" <amit.s...@redhat.com>, >>>>> jasow...@redhat.com, "Wei Xu" <w...@redhat.com>, >>>>> arm...@redhat.com >>>>> Sent: Thursday, June 2, 2016 2:38:53 PM >>>>> Subject: Re: [Qemu-devel] [RFC Patch 0/3] Accept passed in socket >>>>> 'fd' open from outside for unix socket >>>>> >>>>> On 02.06.2016 10:29, Daniel P. Berrange wrote: >>>>>> On Thu, Jun 02, 2016 at 09:41:56AM +0200, Michal Privoznik wrote: >>>>>>> On 01.06.2016 18:16, Wei Xu wrote: >>>>>>>> On 2016年06月01日 00:44, Daniel P. Berrange wrote: >>>>>>>>> On Wed, Jun 01, 2016 at 12:30:44AM +0800, w...@redhat.com wrote: >>>>>>>>>> From: Wei Xu <w...@redhat.com> >>>>>>>>>> >>>>>>>>>> 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. >>>>>>>> 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. >>>>>>>> >>>>>>>> Michael, do you have any comment on this? >>>>>>> >>>>>>> I haven't seen the patches. But in libvirt we allow users to create a >>>>>>> vhostuser interface and even specify where the socket should be placed: >>>>>>> >>>>>>> <interface type='vhostuser'> >>>>>>> <mac address='52:54:00:ee:96:6c'/> >>>>>>> <source type='unix' path='/tmp/vhost1.sock' mode='server'/> >>>>>>> <model type='virtio'/> >>>>>>> </interface> >>>>>>> >>>>>>> The following cmd line is generated by libvirt then: >>>>>>> >>>>>>> -chardev socket,id=charnet1,path=/tmp/vhost1.sock,server \ >>>>>>> -netdev type=vhost-user,id=hostnet1,chardev=charnet1 \ >>>>>>> -device >>>>>>> virtio-net-pci,netdev=hostnet1,id=net1,mac=52:54:00:ee:96:6c,bus=pci.0,\ >>>>>>> >>>>>>> Now, if we accept only /var/run/openvwitch path in >>>>>>> /interface/source/@path (or whatever path to OVS is), we don't need this >>>>>>> and have users manually label the dir (unless already labeled). But >>>>>>> since we accept just any path in there, we should make sure that qemu is >>>>>>> then able to create the socket. One possible fix would be to allow qemu >>>>>>> create sockets just anywhere in the system. This, however, brings huge >>>>>>> security risks and it's not acceptable IMO. The other option would be >>>>>>> that libvirt would create the socket, and pass its FD to qemu (since >>>>>>> libvirt already is allowed to create sockets anywhere). >>>>>> >>>>>> There are plenty of other places where we allow arbitrary paths in the >>>>>> XML, but which have restrictions imposed by the security drivers. Not >>>>>> least the <channel> devices which have the exact same scenario as this >>>>>> network device, and require use of /var/lib/libvirt/qemu as the directory >>>>>> for the sockets. We certainly do not want to allow QEMU to create sockets >>>>>> anywhere. >>>>>> >>>>>> I don't think we want to grant QEMU svirtt permission to create sockets >>>>>> in the /var/run/openvswitch directory either really.IMHO, users of vhost >>>>>> user should really be using /var/lib/libvirt/qemu, as is used for all >>>>>> other UNIX sockets we create wrt other devices. >>>>> >>>>> Okay. I can live with that; but in that case we should document it >>>>> somewhere, that we guarantee only paths under /var/lib/libvirt/ to be >>>>> accessible and for the rest we do our best but maybe require sys admin >>>>> intervention (e.g. to label the whole tree for a non-standard location). >>>> >>>> Does OVS has some limit for it's sockets to be only in >>>> /var/run/openvswitch ? >> >> As of a recent commit, it can only be in /var/run/openvswitch or a >> subdirectory therein (found in the openvswitch database).
Well, this changes game rules for libvirt. The documentation I've suggested above won't any good. Therefore I think we need to be able to have libvirt opening the socket and then just pass the FD to qemu. Michal
