qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] Live migration - exec: support to be reintroduced?


From: Anthony Liguori
Subject: Re: [Qemu-devel] Live migration - exec: support to be reintroduced?
Date: Wed, 05 Nov 2008 11:30:21 -0600
User-agent: Thunderbird 2.0.0.17 (X11/20080925)

Daniel P. Berrange wrote:
On Wed, Nov 05, 2008 at 09:19:02AM -0600, Anthony Liguori wrote:
Daniel P. Berrange wrote:
It is useful from a security point of view - it means QEMU doesn't
need to be given permissions to create files, merely append to an
opened file handle.

On a related note, Avi pointed out to me that SCM_RIGHTS fd passing
would be important for NIC hotplug to allow parity with -net arg
on the command line. If the QEMU process is running unprivileged,
it will not have rights to create TAP devices & giving it a setuid()
network script is not desirable. The management app invoking QEMU
could open the TAP device, and do any setup before passing the FD
to the NIC hotplug command in the monitor.
Yup. If libvirt has a use case for it, then I'm more than happy to review patches.

I'm always looking for an excuse to use SCM_RIGHTS :-)

I think the monitor interface could use improvement. I think it would look better as:

(qemu) receivefd /path/to/unix/socket
/* waits until it receives an fd on /path/to/unix/socket */
fd=10
(qemu) closefd 10

Then all of the existing uses of fd= can be preserved.

I like the idea of using a temporary socket because you don't have to rely on the monitor being on a unix socket. This will be especially useful when we can support tunneling the monitor through VNC.

Yes, except that I would wouldn't want to pass "/path/to/unix/socket"
via the monitor - that allows any process which can access that path
to potentially open the socket & intercept the credentials.

I don't really see this as a problem.

If I wasn't using a UNIX socket for the monitor already, then I'd
want to be able to pass a FD to a unix socket on the command line
so I know who's on the other end of it. eg, if i was using a hypothetical VNC server transport for the monitor, then perhaps allow

    --monitor vnc,scmrightsfd=7

Or, an explicit --scmrights arg for it

Yeah, the later sounds more reasonable, but I don't really know that I agree that the only safe thing to do is here pass an fd on exec. Please describe an attack scenario where a user could access /path/to/unix/socket that isn't trusted?

Regards,

Anthony Liguori

Daniel





reply via email to

[Prev in Thread] Current Thread [Next in Thread]