From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KxmD6-00054a-Bg for qemu-devel@nongnu.org; Wed, 05 Nov 2008 12:30:28 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KxmD4-00054K-63 for qemu-devel@nongnu.org; Wed, 05 Nov 2008 12:30:27 -0500 Received: from [199.232.76.173] (port=34506 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KxmD4-00054H-0K for qemu-devel@nongnu.org; Wed, 05 Nov 2008 12:30:26 -0500 Received: from qw-out-1920.google.com ([74.125.92.149]:21769) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KxmD3-0000ig-Jp for qemu-devel@nongnu.org; Wed, 05 Nov 2008 12:30:25 -0500 Received: by qw-out-1920.google.com with SMTP id 5so95196qwc.4 for ; Wed, 05 Nov 2008 09:30:24 -0800 (PST) Message-ID: <4911D82D.20900@codemonkey.ws> Date: Wed, 05 Nov 2008 11:30:21 -0600 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] Live migration - exec: support to be reintroduced? References: <49113157.3090101@codemonkey.ws> <20081105100546.GA25523@redhat.com> <491199A2.1040207@redhat.com> <4911AA29.1090101@codemonkey.ws> <20081105143731.GM25523@redhat.com> <4911B966.6070000@codemonkey.ws> <20081105172305.GR25523@redhat.com> In-Reply-To: <20081105172305.GR25523@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Daniel P. Berrange" Cc: qemu-devel@nongnu.org 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 >