On 6/1/20 12:18 PM, Eric Blake wrote:
This raises the question of what password=- actually means. It's
documented as "read a password interactively", with the word
"interactively" going back to at least nbdkit 1.2, and therefore I
think we should reject attempts to use password=- from non-ttys.
Makes sense.
Since at least nbdkit 1.2 we have allowed passwords to be read from
files (password=+FILENAME), and since nbdkit 1.16 you can read
passwords from arbitrary file descriptors (password=-FD).
Another justification for the interactive-only nature of password=- is
that it prints a “password: ” prompt.
So I believe it is fair to ban password=- unless the input is a tty.
I agree with that decision.
And now that I read the code in server/public.c, I'm worried that
password=- and password=-N have the same problem across re-exec: we
blindly call fdopen() on the fd, then blindly call fclose() on the
resulting FILE* - which DOES close the fd. That means that vddk passing
in an fd has the same problem: the passed-in fd will be closed by the
first pass through nbdkit_read_password(), and unavailable for the
second pass after re-exec.
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3226
Virtualization: qemu.org | libvirt.org
_______________________________________________
Libguestfs mailing list
Libguestfs@redhat.com
https://www.redhat.com/mailman/listinfo/libguestfs
