From: "Daniel P. Berrangé" <berrange@redhat.com>
To: Eric Blake <eblake@redhat.com>
Cc: qemu-devel@nongnu.org, "Kevin Wolf" <kwolf@redhat.com>,
"Max Reitz" <mreitz@redhat.com>,
"Markus Armbruster" <armbru@redhat.com>,
"Gerd Hoffmann" <kraxel@redhat.com>,
"Marc-André Lureau" <marcandre.lureau@redhat.com>,
qemu-block@nongnu.org,
"Dr. David Alan Gilbert" <dgilbert@redhat.com>,
"Paolo Bonzini" <pbonzini@redhat.com>,
"Juan Quintela" <quintela@redhat.com>
Subject: Re: [Qemu-devel] [PATCH 2/6] nbd: allow authorization with nbd-server-start QMP command
Date: Tue, 19 Jun 2018 23:07:52 +0100 [thread overview]
Message-ID: <20180619220752.GB19712@redhat.com> (raw)
In-Reply-To: <d10a7833-5e37-52cb-cb5d-25018313469a@redhat.com>
On Tue, Jun 19, 2018 at 03:10:12PM -0500, Eric Blake wrote:
> On 06/15/2018 10:50 AM, Daniel P. Berrangé wrote:
> > From: "Daniel P. Berrange" <berrange@redhat.com>
> >
> > As with the previous patch to qemu-nbd, the nbd-server-start QMP command
> > also needs to be able to specify authorization when enabling TLS encryption.
> >
> > First the client must create a QAuthZ object instance using the
> > 'object-add' command:
> >
> > {
> > 'execute': 'object-add',
> > 'arguments': {
> > 'qom-type': 'authz-simple',
> > 'id': 'authz0',
> > 'parameters': {
> > 'policy': 'deny',
> > 'rules': [
> > {
> > 'match': '*CN=fred',
> > 'policy': 'allow'
> > }
> > ]
> > }
> > }
> > }
> >
> > They can then reference this in the new 'tls-authz' parameter when
> > executing the 'nbd-server-start' command:
> >
> > {
> > 'execute': 'nbd-server-start',
> > 'arguments': {
> > 'addr': {
> > 'type': 'inet',
> > 'host': '127.0.0.1',
> > 'port': '9000'
> > },
> > 'tls-creds': 'tls0',
> > 'tls-authz': 'authz0'
> > }
> > }
>
> Is it worth using a discriminated union (string vs. QAuthZ) so that one
> could specify the authz policy inline rather than as a separate object, for
> convenience? But that would be fine as a followup patch, if we even want
> it.
QAuthZ isn't a QAPI type - its a QOM object interface, so you'd have to
allow the entire object_add arg set inline, and then validate the QOM type
you received after the fact actually implemented the interface. Also for
migration at least it is likely the single authz impl will be shared for
both migration + nbd services. So I think its cleaner just to keep it
separate to avoid having 2 distinct codepaths for handling the same thing
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 :|
next prev parent reply other threads:[~2018-06-19 22:08 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-06-15 15:50 [Qemu-devel] [PATCH 0/6] Add authorization support to all network services Daniel P. Berrangé
2018-06-15 15:50 ` [Qemu-devel] [PATCH 1/6] qemu-nbd: add support for authorization of TLS clients Daniel P. Berrangé
2018-06-19 20:06 ` Eric Blake
2018-06-20 8:42 ` Daniel P. Berrangé
2018-06-15 15:50 ` [Qemu-devel] [PATCH 2/6] nbd: allow authorization with nbd-server-start QMP command Daniel P. Berrangé
2018-06-19 20:10 ` Eric Blake
2018-06-19 22:07 ` Daniel P. Berrangé [this message]
2018-06-15 15:51 ` [Qemu-devel] [PATCH 3/6] migration: add support for a "tls-authz" migration parameter Daniel P. Berrangé
2018-06-15 17:54 ` Dr. David Alan Gilbert
2018-06-18 13:40 ` Daniel P. Berrangé
2018-06-20 10:03 ` Juan Quintela
2018-06-20 10:07 ` Daniel P. Berrangé
2018-06-20 10:11 ` Juan Quintela
2018-06-15 15:51 ` [Qemu-devel] [PATCH 4/6] chardev: add support for authorization for TLS clients Daniel P. Berrangé
2018-06-15 15:51 ` [Qemu-devel] [PATCH 5/6] vnc: allow specifying a custom authorization object name Daniel P. Berrangé
2018-06-19 12:57 ` Daniel P. Berrangé
2018-06-15 15:51 ` [Qemu-devel] [PATCH 6/6] monitor: deprecate acl_show, acl_reset, acl_policy, acl_add, acl_remove Daniel P. Berrangé
2018-06-19 12:31 ` Dr. David Alan Gilbert
2018-06-19 12:52 ` Daniel P. Berrangé
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20180619220752.GB19712@redhat.com \
--to=berrange@redhat.com \
--cc=armbru@redhat.com \
--cc=dgilbert@redhat.com \
--cc=eblake@redhat.com \
--cc=kraxel@redhat.com \
--cc=kwolf@redhat.com \
--cc=marcandre.lureau@redhat.com \
--cc=mreitz@redhat.com \
--cc=pbonzini@redhat.com \
--cc=qemu-block@nongnu.org \
--cc=qemu-devel@nongnu.org \
--cc=quintela@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).