[libvirt] [PATCH] libvirtd: Enable private /tmp under systemd.
Daniel P. Berrange
berrange at redhat.com
Tue Feb 7 12:41:31 UTC 2012
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
I think it would be desirable to have some "managed core dump" API
which always saved dumps into a fixed location under
(as our automatic core dump code already does). Then perhaps have some
APIs to list/delete core dumps, and to download their contents.
|: 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 :|
More information about the libvir-list