[Libguestfs] [PATCH nbdkit] protocol: Implement NBD_OPT_GO.

[Nir Soffer]

On Mon, Aug 6, 2018 at 5:06 PM Eric Blake <eblake at redhat.com> wrote:

> On 08/06/2018 02:54 AM, Richard W.M. Jones wrote:
> > On Sun, Aug 05, 2018 at 12:11:04AM +0300, Nir Soffer wrote:
> >> But we have a bug - server configure to allow access to "export",
> >> but allow access to the default empty "" export.
> >
> > nbdkit ignores the export name you pass in and always has done:
> >
> >
> https://github.com/libguestfs/nbdkit/blob/a2c4e88af503310892ebce6da3ac478beb47888a/src/connections.c#L626
> >
> > The -e option on the command line is only for advertizing an export
> > name to clients.  It is otherwise unused & unenforced.
>
> Agreed - it is not necessarily a bug for the server to permit the client
> to connect to different name(s) than what the server was told to advertise.
>
> >
> > One day we'll do something useful with it but we're not sure what.
>
> We might eventually reject clients that don't request the same export
> name as what was advertised, but that doesn't make the current behavior
> buggy (it only means that current clients shouldn't rely on a mismatched
> name always working).
>

I does not make sense to allow access if the server was configured
with one export, and the user ask for another export. This is likely a bug
in user code or the code running nbdkit.

If users do not want to specify the export, they run nbdkit with empty
export
name, and use empty export name in NBD_OPT_GO. If an export was
specified it should be handled in a strict way.

Here is one use case that will be easily avoided by being strict about
export name:

1. application starts nbdkit on a port
2. application reports port to user
3. application time out, terminating nbdkit
4. applcation starts nbdkit again on same port
   (maybe port range is cycled)
5. application reports port to another user
6. first user access nbdkit, accessing another user disk

If we use random export name, and the server is strict, this failure
is not possible.

Eric, can you point us to the part of the spec allowing ignoring the export
name sent by the client?

Regardless since this is the current behavior we can improve this later.

Nir
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/libguestfs/attachments/20180806/2be67568/attachment.htm>