Re: [Qemu-devel] [PATCH v6 1/3] qemu-nbd: add support for authorization of TLS clients

[Eric Blake <eblake@redhat.com>]

On 2/28/19 12:18 PM, Daniel P. Berrangé wrote:

>> It doesn't hold up this patch, but I note that with the qemu QMP command
>> changes you make in 2/3, you document that the object can be
>> created/removed on the fly, and the server will adjust which clients can
>> then subsequently connect. Is there any need for the same sort of
>> runtime configurability in qemu-nbd, and if so, how would we accomplish
>> it?  Perhaps by having a command-line option to parse --tls-authz from a
>> file, where you can send SIGHUP to qemu-nbd to force it to re-read the
>> file?  Or am I worrying about something unlikely to be needed in practice?
> 
> Well the QAuthZListFile object type can store its contents in an external
> file that gets auto-reloaded upon inotify triggers from the main loop.
> The QAuthZPAM type can also be fairly dynamic depending on its backend.
> I think any single process is unlikely  to need to switch between
> different object types, so this is good enough dynamic support.

That, and QMP nbd-server-start can serve up multiple exports, while
qemu-nbd serves exactly one export.

I also note that my work on incremental backups has raised the topic
that we someday want to support multiple parallel NBD servers.  Right
now, you are limited to exactly one (even though it can server multiple
exports), which makes serving different content to different clients
harder than if you could have different servers on separate ports with
per-server settings on which clients to allow.  Or, if we have tls-authz
items per-export instead of per-server, so that different clients see a
different subset of available exports when doing NBD_OPT_LIST.

> 
> I can't help thinking we should add QMP to qemu-nbd one day though....

Yeah, as QMP nbd server gets more powerful, we may eventually need a
similar monitor interface into controlling a long-running qemu-nbd
process...

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3226
Virtualization:  qemu.org | libvirt.org