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@xxxxxxxxxx +1-919-301-3266 Libvirt virtualization library http://libvirt.org
Attachment:
signature.asc
Description: OpenPGP digital signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list