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. 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. Thoughts? -- Eric Blake eblake@redhat.com +1-919-301-3266 Libvirt virtualization library http://libvirt.org