[libvirt] [PATCH] libvirtd: Enable private /tmp under systemd.
eblake at redhat.com
Mon Feb 6 21:31:55 UTC 2012
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
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.
Eric Blake eblake at redhat.com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 620 bytes
Desc: OpenPGP digital signature
More information about the libvir-list