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

[Sascha Silbe <silbe@linux.vnet.ibm.com>]

Dear Daniel,

"Daniel P. Berrange" <berrange@redhat.com> 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...

Sascha
-- 
Softwareentwicklung Sascha Silbe, Niederhofenstraße 5/1, 71229 Leonberg
https://se-silbe.de/
USt-IdNr. DE281696641