qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Daniel P . Berrangé
Subject: Re: [Qemu-devel] [PATCH v6 1/3] qemu-nbd: add support for authorization of TLS clients
Date: Thu, 28 Feb 2019 18:18:12 +0000
User-agent: Mutt/1.10.1 (2018-07-13)

On Thu, Feb 28, 2019 at 12:11:00PM -0600, Eric Blake wrote:
> On 2/27/19 10:20 AM, Daniel P. Berrangé wrote:
> > From: "Daniel P. Berrange" <address@hidden>
> > 
> > Currently any client which can complete the TLS handshake is able to use
> > the NBD server. The server admin can turn on the 'verify-peer' option
> > for the x509 creds to require the client to provide a x509 certificate.
> > This means the client will have to acquire a certificate from the CA
> > before they are permitted to use the NBD server. This is still a fairly
> > low bar to cross.
> > 
> > This adds a '--tls-authz OBJECT-ID' option to the qemu-nbd command which
> > takes the ID of a previously added 'QAuthZ' object instance. This will
> > be used to validate the client's x509 distinguished name. Clients
> > failing the authorization check will not be permitted to use the NBD
> > server.
> 
> 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.

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

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|



reply via email to

[Prev in Thread] Current Thread [Next in Thread]