On 12/10/10 18:09, Michael Roth wrote: > I think with strictly enforced size limits the major liability for > viewfile is, as you mentioned, users using it to view binary data or > carefully crafted files that can mess up or fool users/shells/programs > interpreting monitor output. > > But plain-text does not include escape sequences, so it's completely > reasonable that we'd scrape them. And I'm not sure if a "(qemu)" in the > text is a potential liability. Would there be any other issues to consider? > > If we can guard against those things, do you agree it wouldn't be an > inherently dangerous interface? State-full, asynchronous RPCs like > copyfile and exec are not really something I'd planned for the initial > release. I think they'll take some time to get right, and a simple > low-risk interface to cover what I'm fairly sure is the most common use > case seems reasonable.
I am still wary of relying on strict limit enforcement. It is the sort of thing that will eventually change without us noticing and we end up with a security hole. IMHO QEMU should not try to do these sorts of things, instead it should provide the transport and control services. I don't think file viewing belongs in QEMU at all. I would be a lot more comfortable if this was implemented as a standalone monitor interface that connected to QEMU's QMP interface. I could then use QMP to perform actions like copying the file to /tmp and if viewing the file caused the monitor to lock up, we wouldn't lose the guest. This could indeed be the start of an external monitor :) Cheers, Jes
