Re: [Qemu-devel] [PATCH] util: secure memfd_create fallback mechanism

[Rafael David Tinoco]

Hello Marc, 

> On Sep 27, 2016, at 08:13, Marc-André Lureau <address@hidden> wrote:
> 
>>> On Tue, Sep 27, 2016 at 03:06:21AM +0000, Rafael David Tinoco wrote:
>>> We should not have QEMU creating unpredictabile filenames in the
>>> first place - any filenames should be determined by libvirt
>>> explicitly.
>> 
>> Note that the filename, per se, is not as important as other files,
>> since qemu won't provide it for being accessed by external programs, and,
>> deletes the file, while keeping the descriptor, right after its creation
>> (due to its nature, that is probably why it was created in /tmp).
>> 
>> Having libvirt to define a filename that would not be used for recent
>> kernels (> 3.17) and would exist for a fraction of second doesn't seem
>> right to me.
>> 
> 
> There are other parts of qemu that rely on creating temporary files, and this 
> seems to lack a bit of uniformity. Would it make sense to define a place 
> where qemu could create those? Or setting TMPDIR should help too. Could 
> libvirt set a per-vm TMPDIR with appropriate security rules?

Best move I can see. Only problem is that if we do that, we would have to 
create a fallback mechanism for when TMPDIR is not set. It would go back to 
/tmp ? 

In my particular case (for 1 vhost log file):

-netdev tap,fd=26,id=hostnet0,vhost=on,vhostfd=28 -device 
virtio-net-pci,netdev=hostnet0,id=net0,mac=fa:16:3e:5c:10:f2,bus=pci.0,addr=0x3

I could have something similar to:

-netdev tap,fd=26,id=hostnet0,vhost=on,vhostfd=28 -device 
virtio-net-pci,netdev=hostnet0,id=net0,mac=fa:16:3e:5c:10:f2,bus=pci.0,addr=0x3,vhostpath=/var/lib/XXXX/YYYY/
 

and put mkstemp() files (one per vhost device) in there. 

Even so, what to do when "vhostpath" is not informed ? 

I'm worried that, right now there are security drivers either blocking the live 
migration entirely or allowing all instances to be able to read 
/tmp/memfd-XXXX. 

Don't you think we could push the first patch until we come up with a better 
approach for the tmp (and default tmp) files & directories ? The patch is not 
worse than what was committed already. 

Tks

Rafael