<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Mon, Aug 6, 2018 at 5:51 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 Mon, Aug 06, 2018 at 05:31:54PM +0300, Nir Soffer wrote:<br>
> On Mon, Aug 6, 2018 at 5:06 PM Eric Blake <<a href="mailto:eblake@redhat.com" target="_blank">eblake@redhat.com</a>> wrote:<br>
> <br>
> > On 08/06/2018 02:54 AM, Richard W.M. Jones wrote:<br>
> > > On Sun, Aug 05, 2018 at 12:11:04AM +0300, Nir Soffer wrote:<br>
> > >> But we have a bug - server configure to allow access to "export",<br>
> > >> but allow access to the default empty "" export.<br>
> > ><br>
> > > nbdkit ignores the export name you pass in and always has done:<br>
> > ><br>
> > ><br>
> > <a href="https://github.com/libguestfs/nbdkit/blob/a2c4e88af503310892ebce6da3ac478beb47888a/src/connections.c#L626" rel="noreferrer" target="_blank">https://github.com/libguestfs/nbdkit/blob/a2c4e88af503310892ebce6da3ac478beb47888a/src/connections.c#L626</a><br>
> > ><br>
> > > The -e option on the command line is only for advertizing an export<br>
> > > name to clients.  It is otherwise unused & unenforced.<br>
> ><br>
> > Agreed - it is not necessarily a bug for the server to permit the client<br>
> > to connect to different name(s) than what the server was told to advertise.<br>
> ><br>
> > ><br>
> > > One day we'll do something useful with it but we're not sure what.<br>
> ><br>
> > We might eventually reject clients that don't request the same export<br>
> > name as what was advertised, but that doesn't make the current behavior<br>
> > buggy (it only means that current clients shouldn't rely on a mismatched<br>
> > name always working).<br>
> ><br>
> <br>
> I does not make sense to allow access if the server was configured<br>
> with one export, and the user ask for another export. This is likely a bug<br>
> in user code or the code running nbdkit.<br>
> <br>
> If users do not want to specify the export, they run nbdkit with empty<br>
> export<br>
> name, and use empty export name in NBD_OPT_GO. If an export was<br>
> specified it should be handled in a strict way.<br>
> <br>
> Here is one use case that will be easily avoided by being strict about<br>
> export name:<br>
> <br>
> 1. application starts nbdkit on a port<br>
> 2. application reports port to user<br>
> 3. application time out, terminating nbdkit<br>
> 4. applcation starts nbdkit again on same port<br>
>    (maybe port range is cycled)<br>
> 5. application reports port to another user<br>
> 6. first user access nbdkit, accessing another user disk<br>
> <br>
> If we use random export name, and the server is strict, this failure<br>
> is not possible.<br>
<br>
Export name validation should not be considered a security feature, as<br>
the export name is not designated or treated as sensitive data.<br></blockquote><div><br></div><div>I did not say this is a security issue.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
If you want to prevent one user access other users' disks, whether by<br>
accidental or maliciously, you need to use TLS and validate clients<br>
certificates in the server, or use the new PSK credentials.</blockquote><div><br></div><div>TLS will work but is not needed if you don't need a secure transport.</div><div><br></div><div>Nir</div><div> <br></div></div></div>