<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Mon, Aug 6, 2018 at 5:06 PM Eric Blake <<a href="mailto:eblake@redhat.com">eblake@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 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>
> <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></blockquote><div><br></div><div>I does not make sense to allow access if the server was configured</div><div>with one export, and the user ask for another export. This is likely a bug</div><div>in user code or the code running nbdkit.</div><div><br></div><div>If users do not want to specify the export, they run nbdkit with empty export</div><div>name, and use empty export name in NBD_OPT_GO. If an export was </div><div>specified it should be handled in a strict way.</div><div><br></div><div>Here is one use case that will be easily avoided by being strict about export name:</div><div><br></div><div>1. application starts nbdkit on a port</div><div>2. application reports port to user</div><div>3. application time out, terminating nbdkit</div><div>4. applcation starts nbdkit again on same port</div><div>   (maybe port range is cycled)</div><div>5. application reports port to another user</div><div>6. first user access nbdkit, accessing another user disk</div><div><br></div><div>If we use random export name, and the server is strict, this failure</div><div>is not possible.</div><div><br></div><div>Eric, can you point us to the part of the spec allowing ignoring the export</div><div>name sent by the client?</div><div><br></div><div>Regardless since this is the current behavior we can improve this later.<br></div><div><br></div><div>Nir</div><div> </div></div></div>