On Thu, Dec 19, 2013 at 11:32:32AM -0700, Eric Blake wrote:
> On 12/19/2013 08:23 AM, Daniel P. Berrange wrote:
> > On Thu, Dec 19, 2013 at 08:15:09AM -0700, Eric Blake wrote:
> >> diff --git a/src/libvirt-qemu.c b/src/libvirt-qemu.c
> >> index db52c65..849932d 100644
>
> >> + if (dom &&
> >> + !(VIR_IS_CONNECTED_DOMAIN(dom) && dom->conn == conn)) {
> >> + virLibConnError(VIR_ERR_INVALID_CONN, __FUNCTION__);
> >> + virDispatchError(conn);
> >> + return -1;
> >> + }
> >> + virCheckNonNullArgGoto(cb, error)
> >
> >
> > I have a gut feeling that we should restrict use of this API to
> > authenticated users only. So add a check for a read-only connection
> > here
>
> Hmm. It would match what we have for qemu-monitor-command; on the other
> hand, it differs from what we have for normal events (libvirt events are
> fine on a read-only connection). I guess an argument in favor of
> requiring write privileges is that qemu may expose details in its events
> that are better left internal to libvirt (that is, libvirt has a chance
> to scrub details before handing information to read-only guests, but
> with raw event handling, there is no scrubbing). And it's always easier
> to relax things later than it is to add read-write restrictions later
> and break existing callers that had grown used to read-only.
Yes, my concern is that there could one day be a QEMU event that includes
some sensitive information in its parameters. Normal users should never
need to use this API anyway, so restricting its access shouldn't really
hurt people.
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