Libguestfs - Aug 2018 - Re: [PATCH nbdkit] protocol: Implement NBD_OPT_GO.

On 08/06/2018 09:31 AM, Nir Soffer wrote:
> Eric, can you point us to the part of the spec allowing ignoring the export
> name sent by the client?
Nothing in the NBD spec requires the server to reject unknown export 
names. So nbdkit never rejects export names (which means it behaves as 
if all names work, regardless of whether or not it was the name it was 
configured with, since it exports exactly one volume all the time).

An NBD server that exports more than one volume at a time (such as qemu 
via QMP [but oddly not qemu-nbd], or nbd-server) DOES have to pay 
attention to export names. And if nbdkit were ever taught to manage more 
than one export at once, then that would also imply that export names 
matter.  But until then, I don't see nbdkit's behavior as a spec
violation.

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3266
Virtualization:  qemu.org | libvirt.org

On Mon, Aug 6, 2018 at 5:46 PM Eric Blake <eblake@redhat.com> wrote:
> On 08/06/2018 09:31 AM, Nir Soffer wrote:
> > Eric, can you point us to the part of the spec allowing ignoring the
> export
> > name sent by the client?
>
> Nothing in the NBD spec requires the server to reject unknown export
> names. So nbdkit never rejects export names (which means it behaves as
> if all names work, regardless of whether or not it was the name it was
> configured with, since it exports exactly one volume all the time).
>
The spec mention this about NBD_OPT_EXPORT_NAME:

   If the chosen export does not exist or requirements for the chosen
export are not met
    (e.g., the client did not initiate TLS for an export where the server
requires it), the
    server MUST terminate the session.

and for NBD_OPT_GO, we have NBD_REP_ERR_UNKNOWN:

    The chosen export does not exist on this server. In this case, the
server SHOULD NOT
    send NBD_REP_INFO replies.

And the spec also says:

    If the server is unwilling to allow the export, it MUST terminate the
session

Why would a server want to allow an export using different name? What is
the point
of the export name in this case?

Again, if export name is not useful when a server export only one export,
both server and
client can use the default empty export name.

Nir

On Mon, Aug 06, 2018 at 08:05:00PM +0300, Nir Soffer
wrote:
> On Mon, Aug 6, 2018 at 5:46 PM Eric Blake <eblake@redhat.com> wrote:
> 
> > On 08/06/2018 09:31 AM, Nir Soffer wrote:
> > > Eric, can you point us to the part of the spec allowing ignoring
the
> > export
> > > name sent by the client?
> >
> > Nothing in the NBD spec requires the server to reject unknown export
> > names. So nbdkit never rejects export names (which means it behaves as
> > if all names work, regardless of whether or not it was the name it was
> > configured with, since it exports exactly one volume all the time).
> >
> 
> The spec mention this about NBD_OPT_EXPORT_NAME:
> 
>    If the chosen export does not exist or requirements for the chosen
> export are not met
>     (e.g., the client did not initiate TLS for an export where the server
> requires it), the
>     server MUST terminate the session.
> 
> and for NBD_OPT_GO, we have NBD_REP_ERR_UNKNOWN:
> 
>     The chosen export does not exist on this server. In this case, the
> server SHOULD NOT
>     send NBD_REP_INFO replies.
> 
> And the spec also says:
> 
>     If the server is unwilling to allow the export, it MUST terminate the
> session
> 
> Why would a server want to allow an export using different name? What is
> the point
> of the export name in this case?
> 
> Again, if export name is not useful when a server export only one export,
> both server and
> client can use the default empty export name.
I still don't believe that we're contravening the protocol, since we
get to define what the "requirements" are (ie. none).  Also
"SHOULD"
not "MUST".

The real problem is that export name is a barrier to usage.  Beginners
have no idea what it is, why it's needed, what it is set to, or how to
find out.  They will connect to the server, it will fail, they'll give
up and think NBD or nbdkit is broken.

So I don't want to enforce export names until they have a purpose,
which they don't have in nbdkit because we can only ever have a single
plugin loaded.

In the case you mentioned before of a client connecting to the wrong
server, I would suggest using PSK with a fresh key each time.  This
has the additional benefit of being secure.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
libguestfs lets you edit virtual machines.  Supports shell scripting,
bindings from many languages.  http://libguestfs.org

On 08/06/2018 12:05 PM, Nir Soffer wrote:
> On Mon, Aug 6, 2018 at 5:46 PM Eric Blake <eblake@redhat.com> wrote:
> 
>> On 08/06/2018 09:31 AM, Nir Soffer wrote:
>>> Eric, can you point us to the part of the spec allowing ignoring
the
>> export
>>> name sent by the client?
>>
>> Nothing in the NBD spec requires the server to reject unknown export
>> names. So nbdkit never rejects export names (which means it behaves as
>> if all names work, regardless of whether or not it was the name it was
>> configured with, since it exports exactly one volume all the time).
>>
> 
> The spec mention this about NBD_OPT_EXPORT_NAME:
> 
>     If the chosen export does not exist or requirements for the chosen
> export are not met
>      (e.g., the client did not initiate TLS for an export where the server
> requires it), the
>      server MUST terminate the session.
But in the case of nbdkit, ALL export names exist (not just the one you 
configured with), since the name has no meaning other than what is 
reported over the wire to NBD_OPT_LIST.
> 
> and for NBD_OPT_GO, we have NBD_REP_ERR_UNKNOWN:
> 
>      The chosen export does not exist on this server. In this case, the
> server SHOULD NOT
>      send NBD_REP_INFO replies.
That's what happens when the server does not want to accept the name 
given by the client, but does not prevent a server from accepting ALL 
names (by ignoring the name).
> 
> And the spec also says:
> 
>      If the server is unwilling to allow the export, it MUST terminate the
> session
> 
> Why would a server want to allow an export using different name? What is
> the point
> of the export name in this case?
In the case of nbdkit, the point of not caring about names is a matter 
of convenience - with exactly one thing being exported, naming that 
thing doesn't matter, so we can get to the connection faster and with 
less code without having to validate something that didn't matter.

As mentioned elsewhere in the thread, someday we may have a reason to 
care, at which point name validation will make sense. And a portable 
client cannot blindly assume that it is going to work to ask for a 
different name than what is returned in NBD_OPT_LIST (but note also that 
the spec does not require clients to call NBD_OPT_LIST in the first 
place).  But at the same time, a client cannot assume that only the 
names returned in NBD_OPT_LIST will work.
> 
> Again, if export name is not useful when a server export only one export,
> both server and
> client can use the default empty export name.
Yes, the empty name is one (of a large number, but not truly infinite, 
due to length limitations) of the possible valid names that nbdkit 
otherwise ignores.

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3266
Virtualization:  qemu.org | libvirt.org