<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Thu, Jun 28, 2018 at 6:56 PM Daniel P. Berrangé <<a href="mailto:berrange@redhat.com">berrange@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Thu, Jun 28, 2018 at 10:18:25AM -0500, Eric Blake wrote:<br>
> On 06/25/2018 12:01 PM, Richard W.M. Jones wrote:<br>
> > ---<br>
> > docs/<a href="http://nbdkit.pod.in" rel="noreferrer" target="_blank">nbdkit.pod.in</a> | 45 +++++++++--<br>
> > src/crypto.c | 234 +++++++++++++++++++++++++++++++++++++----------------<br>
> > src/internal.h | 1 +<br>
> > src/main.c | 8 +-<br>
> > 4 files changed, 210 insertions(+), 78 deletions(-)<br>
> > <br>
> <br>
> > +Create a PSK file containing one or more C<username:key> pairs. It is<br>
> > +easiest to use L<psktool(1)> for this:<br>
> > +<br>
> > + psktool -u rich -p /tmp/psk<br>
> > +<br>
> > +The PSK file contains the hex-encoded random keys in plaintext. Any<br>
> > +client which can read this file will be able to connect to the server.<br>
> <br>
> If I'm understanding correctly, it's also possible for a server to create a<br>
> file that supports multiple users:<br>
> <br>
> c1:1234<br>
> c2:2345<br>
> <br>
> but then hand out a smaller file to client c1 that contains only the c2:1234<br>
> line, and another small file to client c2, and then a single server can not<br>
> only accept multiple clients but also distinguish which client connected. Is<br>
> there any reason for nbdkit as a server to additionally limit which<br>
> resources are served depending on which client connected?<br>
> <br>
> But that's probably overkill for now; as it's just as easy to point nbdkit<br>
> to the smaller file in the first place, and since right now nbdkit serves up<br>
> at most one file, provided the client can connect in the first place (it<br>
> would matter more for something like nbd-server, which has an init file that<br>
> specifies multiple resources served by a single server, and therefore might<br>
> want per-user restrictions on those resources).<br>
<br>
I could see a situation where a host has a single file of keys + users used<br>
for all NBD servers, and then whitelists specific user names per instance.<br>
Not a blocker, but conceptually relevant. When I add the authorization work<br>
to QEMU I'd intend to use that to authorize the client username.</blockquote><div><br></div><div>I don't think we should make it easy to have a static files with many keys and</div><div>user names. Shared key should be used exactly once, for single operation.</div><div>This means that you cannot loose the key and you don't need to manage it.</div><div><br></div><div>It would be best if we could pass the key to without writing it to actual file</div><div>so we don't have to clean it up later.</div><div><br></div><div>Nir</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<br>
Regards,<br>
Daniel<br>
-- <br>
|: <a href="https://berrange.com" rel="noreferrer" target="_blank">https://berrange.com</a> -o- <a href="https://www.flickr.com/photos/dberrange" rel="noreferrer" target="_blank">https://www.flickr.com/photos/dberrange</a> :|<br>
|: <a href="https://libvirt.org" rel="noreferrer" target="_blank">https://libvirt.org</a> -o- <a href="https://fstop138.berrange.com" rel="noreferrer" target="_blank">https://fstop138.berrange.com</a> :|<br>
|: <a href="https://entangle-photo.org" rel="noreferrer" target="_blank">https://entangle-photo.org</a> -o- <a href="https://www.instagram.com/dberrange" rel="noreferrer" target="_blank">https://www.instagram.com/dberrange</a> :|<br>
<br>
_______________________________________________<br>
Libguestfs mailing list<br>
<a href="mailto:Libguestfs@redhat.com" target="_blank">Libguestfs@redhat.com</a><br>
<a href="https://www.redhat.com/mailman/listinfo/libguestfs" rel="noreferrer" target="_blank">https://www.redhat.com/mailman/listinfo/libguestfs</a><br>
</blockquote></div></div>