Re: [Qemu-devel] [PATCH v3 4/4] qemu-config: Add new -add-fd command line option

[Eric Blake <eblake@redhat.com>]

[-- Attachment #1: Type: text/plain, Size: 1571 bytes --]

On 10/17/2012 08:02 AM, Kevin Wolf wrote:
> Am 17.10.2012 06:16, schrieb Eric Blake:
>> I'm still seeing the corner case of:
>>
>> qemu-kvm -add-fd fd=3,set=1 -add-fd fd=4,set=2 4<&-
>>
>> where the dup(3) will populate fd 4 prior to the point where we get to
>> process the -add-fd fd=4 command to notice that the user started
>> qemu-kvm with fd 4 closed, and thus qemu will silently proceed to use
>> the wrong fd.
>>
>> On the other hand, I'm not sure if that corner case is worth worrying
>> about, or if we just chalk it up to user stupidity (aka libvirt
>> programmer stupidity) if they did something like that (most likely,
>> because the management app forgot to clear FD_CLOEXEC before exec()ing
>> qemu-kvm).
> 
> If you specify an FD number that isn't actually open when qemu is
> stared, you can get any FD that qemu opens internally. I think the
> correct answer to this problem is "then don't do that".

Overnight, I realized we do have one potential safety valve: we are
guaranteed that any fd inherited by the exec() of qemu-kvm has
FD_CLOEXEC clear, and we also strive to have qemu open/dup all of its
internal fds with FD_CLOEXEC set.  Therefore, it may be worth a sanity
check of fcntl(F_GETFD) to see if FD_CLOEXEC is set, and if so, the user
must have failed to pass in the fd, and we are now looking at a qemu
internal fd, and should therefore report failure.  But I'm not sure if
it's worth the extra code.

-- 
Eric Blake   eblake@redhat.com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 617 bytes --]