On Mon, Feb 06, 2012 at 02:31:55PM -0700, Eric Blake wrote:
On 02/06/2012 02:15 PM, Eric Blake wrote:
The last intentional use of /tmp by libvirt was patched in commit bd6083c9b; we can add an extra measure of security by explicitly requesting that libvirtd's /tmp is not visible to arbitrary users. See https://bugzilla.redhat.com/782474
* daemon/libvirtd.service.in (Service): Enable PrivateTmp. --- daemon/libvirtd.service.in | 1 + 1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/daemon/libvirtd.service.in b/daemon/libvirtd.service.in index 8f2458a..cf68440 100644 --- a/daemon/libvirtd.service.in +++ b/daemon/libvirtd.service.in @@ -17,6 +17,7 @@ ExecStart=@sbindir@/libvirtd $LIBVIRTD_ARGS ExecReload=/bin/kill -HUP $MAINPID # Override the maximum number of opened files #LimitNOFILE=2048 +PrivateTmp=true
Before acking this patch, you should bear in mind that some users (for better or worse) _like_ to have libvirtd interact with /tmp. For example, 'virsh screenshot domain /tmp/sreen.ppm' would store into the user's /tmp (the API uses a stream, with the client side piping the stream into the client's file system), while 'virsh dump domain /tmp/dom.dump' would store into libvirtd's /tmp. If the two are not the same /tmp, that could break particular use cases.
Actually the screenshot command is one of the well designed ones that would *not* have a problem. It uses streams, so the PATH is interpreted client side, not server side. The problem APIs are virDomainSave/Restore/CoreDump.
I think that argues in part that we should be adding new API counterparts to anything that currently takes a filename, to give a stream alternative that works regardless of how libvirtd is mounted differently than the calling user (also good for remote connections, as 'virsh dump' over a remote connection is already quite sensitive to differences in file system layout between client and host). But maybe it means we should NAK this patch.
We have the managed save APIs and snapshot APIs which avoid the problem of file paths that virDomainSave/Restore have, so I'm not too concerned about those. The virDomainCoreDump AP is the main one without a good solution. I think it would be desirable to have some "managed core dump" API which always saved dumps into a fixed location under /var/lib/libvirt/dumps (as our automatic core dump code already does). Then perhaps have some APIs to list/delete core dumps, and to download their contents. 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 :|