Re: [Qemu-devel] Channel paths (was: Re: [RFC Patch 0/3] Accept passed in socket 'fd' open from outside for unix socket)

[Daniel P. Berrange]

On Thu, Jun 02, 2016 at 09:27:45PM +0200, Sascha Silbe wrote:
> Dear Daniel,
> 
> "Daniel P. Berrange" <address@hidden> writes:
> 
> > 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:
> > 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.
> 
> Umm, how exactly is an application supposed to use (i.e. open) the
> channel devices defined in XML?
> 
> 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.
> 
> 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
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|