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

[Anthony Liguori <anthony@codemonkey.ws>]

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
>