On Mon, 26 Oct 2026 16:19:41 +0000
"Lawrence, Richard E"
[...]
I wanted to unconditionally relocate the fd_tap because I imagined the following bug: imagine if someone is using pasta, passes the tap on stdin, does NOT request to pass fds (tap | pasta -fd 0), and we choose not to relocate the tap. Since stdin is never closed, the tap would be passed to the spawned command on stdin, which would most likely causing the spawned command to have unexpected behavior.
Oh, you're right, I didn't consider that possibility. I thought that moving the tap file descriptor would only be relevant if we later close file descriptors, but that's not actually the case. I'll review your v3 in a bit. I just had a glance and I couldn't figure out right away why the second part of the change in isolate_fds() isn't a simple: if (!c->pasta_pass_fds) return; in the right place (after the --fd descriptor is moved, then), but I guess I'll figure it out. :)
Additionally, this choice is especially weird considering that the hypothetical user did not even request the tap to be passed to the spawned command at all. I would also like to point out that the code already unconditionally relocates the tap: I assume that someone must have foreseen some other bug (perhaps related to stdin in passt mode?) and I don't want to cause a regression in another workflow that I don't know anything about.
Your assumption is correct, exactly that, see: https://bugs.passt.top/show_bug.cgi?id=215 https://github.com/libguestfs/libguestfs/issues/360#issuecomment-4939858744 as well as commits: c80d9db312df ("main: Ensure fds 0-2 are populated") fd5b0807f5d0 ("isolation: Move --fd descriptor to a number of our choosing") -- Stefano