On Mon, Aug 6, 2018 at 5:51 PM Daniel P. Berrangé <berra...@redhat.com> wrote:
> On Mon, Aug 06, 2018 at 05:31:54PM +0300, Nir Soffer wrote: > > On Mon, Aug 6, 2018 at 5:06 PM Eric Blake <ebl...@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. > I did not say this is a security issue. 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. TLS will work but is not needed if you don't need a secure transport. Nir
_______________________________________________ Libguestfs mailing list Libguestfs@redhat.com https://www.redhat.com/mailman/listinfo/libguestfs
