From: "Daniel P. Berrangé" <berrange@redhat.com>
To: Eric Blake <eblake@redhat.com>
Cc: qemu-devel@nongnu.org,
"open list:Network Block Dev..." <qemu-block@nongnu.org>,
rjones@redhat.com
Subject: Re: [Qemu-devel] [PATCH] qemu-nbd: Permit TLS with Unix sockets
Date: Thu, 27 Jun 2019 15:58:50 +0100 [thread overview]
Message-ID: <20190627145850.GN12358@redhat.com> (raw)
In-Reply-To: <a3418db6-4bb4-029e-8a5d-d9e6b1185f22@redhat.com>
On Thu, Jun 27, 2019 at 09:49:13AM -0500, Eric Blake wrote:
> On 6/26/19 3:22 AM, Daniel P. Berrangé wrote:
> > On Tue, Jun 25, 2019 at 09:49:42PM -0500, Eric Blake wrote:
> >> Although you generally won't use encryption with a Unix socket (after
> >> all, everything is local, so why waste the CPU power), there are
> >> situations in testsuites where Unix sockets are much nicer than TCP
> >> sockets. Since nbdkit allows encryption over both types of sockets,
> >> it makes sense for qemu-nbd to do likewise.
> >>
> >> Signed-off-by: Eric Blake <eblake@redhat.com>
> >> ---
> >> qemu-nbd.c | 4 ----
> >> 1 file changed, 4 deletions(-)
> >
> > Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
> >
> >
> > Do you need something on the client side too ?
>
> The proposal that Rich is working on for standardized NBD URIs [1] says
> that we need a patch to support nbds://host/export and
> nbds+unix://export?socket=/path as ways to request an encrypted client
> connection with default encryption parameters. For anything more
> complex, we have to use --imageopts and request an encrypted connection
> by parts - but the QAPI schema already permits us to pass in an
> 'tls-creds' parameter for both TCP and Unix sockets, so no, I don't
> think we need any client side changes at this point.
The QAPI schema isn't what I was thinking about.... in block/nbd.c
we have the same restriction you lifted here
tlscreds = nbd_get_tls_creds(s->tlscredsid, errp);
if (!tlscreds) {
goto error;
}
/* TODO SOCKET_ADDRESS_KIND_FD where fd has AF_INET or AF_INET6 */
if (s->saddr->type != SOCKET_ADDRESS_TYPE_INET) {
error_setg(errp, "TLS only supported over IP sockets");
goto error;
}
For client side we would also need to allow a 'tls-hostname' parameter
in BlockdevOptionsNbd, so that the client can pass a hostname to use
for validating the x509 certificate, the same way we allow for live
migration.
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:[~2019-06-27 15:00 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-06-26 2:49 [Qemu-devel] [PATCH] qemu-nbd: Permit TLS with Unix sockets Eric Blake
2019-06-26 8:22 ` Daniel P. Berrangé
2019-06-27 14:49 ` Eric Blake
2019-06-27 14:58 ` Daniel P. Berrangé [this message]
2019-06-27 15:37 ` Eric Blake
2019-06-26 8:52 ` Richard W.M. Jones
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=20190627145850.GN12358@redhat.com \
--to=berrange@redhat.com \
--cc=eblake@redhat.com \
--cc=qemu-block@nongnu.org \
--cc=qemu-devel@nongnu.org \
--cc=rjones@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.