On Mon, Aug 06, 2018 at 05:31:54PM +0300, Nir Soffer wrote:
> On Mon, Aug 6, 2018 at 5:06 PM Eric Blake <eblake@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.

Export name validation should not be considered a security feature, as
the export name is not designated or treated as sensitive data.

If you want to prevent one user access other users' disks, whether by
accidental or maliciously, you need to use TLS and validate clients
certificates in the server, or use the new PSK credentials.