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 solution. I think it would be desirable to have some "managed core dump" API which always saved dumps into a fixed location under /var/lib/libvirt/dumps (as our automatic core dump code already does). Then perhaps have some APIs to list/delete core dumps, and to download their contents. Regards, Daniel -- |: 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 :| -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list