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.
Thoughts?
--
Eric Blake eblake(a)redhat.com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
Attachments:
- signature.asc (application/pgp-signature — 620 bytes)