From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:50737) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1b8kYk-0001xo-Dv for qemu-devel@nongnu.org; Fri, 03 Jun 2016 04:34:27 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1b8kYh-0006O0-3o for qemu-devel@nongnu.org; Fri, 03 Jun 2016 04:34:26 -0400 Received: from mx1.redhat.com ([209.132.183.28]:45866) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1b8kYg-0006Nv-Ra for qemu-devel@nongnu.org; Fri, 03 Jun 2016 04:34:23 -0400 Date: Fri, 3 Jun 2016 09:34:18 +0100 From: "Daniel P. Berrange" Message-ID: <20160603083418.GB13827@redhat.com> Reply-To: "Daniel P. Berrange" References: <1464712247-11655-1-git-send-email-wexu@redhat.com> <20160531164448.GE21628@redhat.com> <574F0A7B.5030401@redhat.com> <01045d4a-f03d-9f0d-deeb-4927446bb894@redhat.com> <20160602082904.GD9481@redhat.com> <201606021927.u52JB3YU031760@mx0a-001b2d01.pphosted.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <201606021927.u52JB3YU031760@mx0a-001b2d01.pphosted.com> Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] Channel paths (was: Re: [RFC Patch 0/3] Accept passed in socket 'fd' open from outside for unix socket) List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Sascha Silbe Cc: Michal Privoznik , qemu-devel@nongnu.org, amit.shah@redhat.com, jasowang@redhat.com, Wei Xu , armbru@redhat.com On Thu, Jun 02, 2016 at 09:27:45PM +0200, Sascha Silbe wrote: > Dear Daniel, >=20 > "Daniel P. Berrange" writes: >=20 > > On Thu, Jun 02, 2016 at 09:41:56AM +0200, Michal Privoznik wrote: > >> On 01.06.2016 18:16, Wei Xu wrote: > >> > On 2016=E5=B9=B406=E6=9C=8801=E6=97=A5 00:44, Daniel P. Berrange w= rote: > > There are plenty of other places where we allow arbitrary paths in th= e > > XML, but which have restrictions imposed by the security drivers. Not > > least the devices which have the exact same scenario as thi= s > > network device, and require use of /var/lib/libvirt/qemu as the direc= tory > > for the sockets. We certainly do not want to allow QEMU to create soc= kets > > anywhere. >=20 > Umm, how exactly is an application supposed to use (i.e. open) the > channel devices defined in XML? >=20 > Previously I deliberately left out the path in the XML to let libvirt > choose the path and extracted it from the XML after defining the > domain. This ensured qemu could access the path, plus it was the > responsibility of libvirt to clean it up once the domain was > undefined. Easy and simple. >=20 > Since 71408079 [qemu: Don't bother user with libvirt-internal paths], > the path chosen by libvirt isn't included in the domain XML anymore. So > now I need to choose the path inside the application. The only safe way > to do that is by using something in an application-managed namespace > (e.g. /var/lib/myapp/foo or /tmp/myapp/foo); I certainly wouldn't want > to second guess what paths would be safe inside the libvirt namespace > (/var/lib/libvirt/qemu). Except now I hear that anything outside > /var/lib/libvirt/qemu is not guaranteed to work due to e.g. the SELinux > policy configured by libvirt... IIUC that change 71408079 ought to only apply to the persistent XML configuration on disk. When the guest is running the live XML ought to still report the path libvirt chose, so you should still be able to see it while running. If that isn't the case then please raise a bug, because we certainly expect apps to be able to discover the path libvirt picked for exactly the reason you describe Regards, Daniel --=20 |: http://berrange.com -o- http://www.flickr.com/photos/dberrange= / :| |: http://libvirt.org -o- http://virt-manager.or= g :| |: http://autobuild.org -o- http://search.cpan.org/~danberr= / :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vn= c :|