Re: [libvirt] [PATCH] libvirtd: Enable private /tmp under systemd.

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.