On Tue, Sep 27, 2016 at 03:06:21AM +0000, Rafael David Tinoco wrote: > Commit: 35f9b6ef3acc9d0546c395a566b04e63ca84e302 added a fallback > mechanism for systems not supporting memfd_create syscall (started > being supported since 3.17).
This is really dubious code in general and IMHO should just be reverted. We have a golden rule that any time QEMU needs to be able to create a file on disk, then the path should be explicitly provided as a command line argument so that mgmt apps can control the location used. > Backporting memfd_create might not be accepted for distros relying > on older kernels. Nowadays there is no way for security driver > to discover memfd filename to be created: <tmpdir>/memfd-XXXXXX. > > It is more appropriate to include UUID and/or VM names in the > temporary filename, allowing security driver rules to be applied > while maintaining the required unpredictability with mkstemp. We should not have QEMU creating unpredictabile filenames in the first place - any filenames should be determined by libvirt explicitly. > This change will allow libvirt to know exact memfd file to be created > for vhost log AND to create appropriate security rules to allow access > per instance (instead of a opened rule like <tmpdir>/memfd-*). Even with this change it is bad - we don't want driver backends creating arbitrary files in the shared /tmp directory. 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 :|