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