We have a couple of password-related commands, and I'm not sure about
which ones should be used. In order of appearance:
* HMP change vnc
Change a VNC server password. Unlike set_password below, there's no
way to select a display other than the first.
Note: if change's second argument isn't "vnc", w're changing removable
media. If you call your block device "vnc", you cannot change its
media. Hilarious.
Password prompting (with hidden user input) since commit 7084851534
"VNC password authentication, by Daniel P. Berrange." (v0.9.1,
2007-08-25).
Password argument since commit 2569da0cb6 "Accept password as an
argument to 'change vnc password' monitor command (Chris Webb)"
(v0.10.0, 2008-12-10).
Nowadays, this wraps around QMP change-vnc-password, discussed below.
* HMP and QMP set_password, expire_password
Change a VNC or Spice server password. For Spice, can optionally fail
when connections exist, or disconnect them.
HMP commands wrap around the respective QMP command, as they should.
HMP set_password does not support password prompting like "change vnc"
does.
Commands are present even when both CONFIG_VNC and CONFIG_SPICE are
off. Attempts to use them are rejected manually. Defeats
introspection.
Since commit 7572150c18 "vnc/spice: add set_passwd monitor command."
(v0.14.0, 2010-12-09)
Support for VNC displays other than the first since commit 675fd3c96b
"qapi/monitor: allow VNC display id in set/expire_password" (v7.0.0,
2022-03-02).
* QMP change-vnc-password
Can only target the first VNC display, unlike set_password.
Command present only with CONFIG_VNC.
Since commit 270b243f91 "qapi: Introduce change-vnc-password" (v1.1,
2012-01-18).
Do we really need / want both set_password and change-vnc-password in
QMP?
On the one hand, set_password feels outdated from a QAPI point of view:
it violates the naming rules, and it defeats introspection. On the
other hand, it's more powerful.
Do we really need / want both set_password and "change vnc" in HMP?
set_password is more powerful, but only "change vnc" supports password
prompting.
Getting rid of "change vnc" would fix the "cannot change media for block
device named 'vnc'" wart.
Related: QCryptoSecret objects.
commit ac1d88784907c9603b3849b2c3043259f75ed2a5
Author: Daniel P. Berrangé <berra...@redhat.com>
Date: Wed Oct 14 09:58:38 2015 +0100
crypto: add QCryptoSecret object class for password/key handling
Introduce a new QCryptoSecret object class which will be used
for providing passwords and keys to other objects which need
sensitive credentials.
The new object can provide secret values directly as properties,
or indirectly via a file. The latter includes support for file
descriptor passing syntax on UNIX platforms. Ordinarily passing
secret values directly as properties is insecure, since they
are visible in process listings, or in log files showing the
CLI args / QMP commands. It is possible to use AES-256-CBC to
encrypt the secret values though, in which case all that is
visible is the ciphertext. For ad hoc developer testing though,
it is fine to provide the secrets directly without encryption
so this is not explicitly forbidden.
The anticipated scenario is that libvirtd will create a random
master key per QEMU instance (eg /var/run/libvirt/qemu/$VMNAME.key)
and will use that key to encrypt all passwords it provides to
QEMU via '-object secret,....'. This avoids the need for libvirt
(or other mgmt apps) to worry about file descriptor passing.
It also makes life easier for people who are scripting the
management of QEMU, for whom FD passing is significantly more
complex.
Providing data inline (insecure, only for ad hoc dev testing)
$QEMU -object secret,id=sec0,data=letmein
Providing data indirectly in raw format
printf "letmein" > mypasswd.txt
$QEMU -object secret,id=sec0,file=mypasswd.txt
Providing data indirectly in base64 format
$QEMU -object secret,id=sec0,file=mykey.b64,format=base64
Providing data with encryption
$QEMU -object secret,id=master0,file=mykey.b64,format=base64 \
-object secret,id=sec0,data=[base64 ciphertext],\
keyid=master0,iv=[base64 IV],format=base64
Note that 'format' here refers to the format of the ciphertext
data. The decrypted data must always be in raw byte format.
More examples are shown in the updated docs.
Reviewed-by: Eric Blake <ebl...@redhat.com>
Signed-off-by: Daniel P. Berrange <berra...@redhat.com>
Currently used by various block backends and the tls-creds-x509 object.
Would it make sense with display servers, too?
