> -----Original Message-----
> From: SPDK [mailto:spdk-bounces(a)lists.01.org] On Behalf Of Howell, Seth
> Sent: Monday, January 7, 2019 6:36 PM
> To: Storage Performance Development Kit <spdk(a)lists.01.org>
> Cc: Eyal Shnitzer <eyal.shnitzer(a)kaminario.com>
> Subject: Re: [SPDK] Access control on the subsystem NQN
> 
> Hi Shahar,
> 
> These are great questions!
> 
> The first one I am just answering intuitively, I think that if a host is removed from
> from the subsystem whitelist, all of its connections should be dropped. I can't
> think of an instance where we would want an unauthorized host to maintain
> access to storage resources for an arbitrary amount of time.
> 
> In regards to the second question, I found the following from the spec:
> "NVMe over Fabrics defines a discovery mechanism that a host uses to
> determine the NVM subsystems that expose namespaces that the host may
> access. The discovery Service provides a host with the following capabilities:
> The ability to discover a list of NVM subsystems with namespaces that are
> accessible to the host; . . . "
> This quote makes it sound to me that if a host is not allowed to access a
> namespace, that namespace should not be returned to that host when it makes
> a discovery request.
> I will defer to Ben if he wants to shoot me down on this, but I think that if you
> want to close all of the connections between a subsystem and a host is removed
> from its ACL, and change the way the discovery service works.

I concur. These are both bugs - the connections should drop and the subsystem should not show up
in the discovery log if the host does not have access/loses access to the subsystem.

> 
> Something to think about is that we are planning to add (NVMe in-band)
> authentication support in 19.04. I am in the early stages of investigating this, but
> it seems that authentication and the subsystem host access lists are
> complimentary and the implementation of one should not directly affect the
> other. Theoretically could use any combination of providing whitelists of hosts
> to each subsystem, and allowing any host to connect to a subsystem but
> requiring authentication before submitting any I/O or admin requests.
> 
> Thanks,
> 
> Seth
> 
> 
> 
> 
> -----Original Message-----
> From: SPDK [mailto:spdk-bounces(a)lists.01.org] On Behalf Of Shahar Salzman
> Sent: Monday, December 31, 2018 8:14 AM
> To: Storage Performance Development Kit <spdk(a)lists.01.org>
> Cc: Eyal Shnitzer <eyal.shnitzer(a)kaminario.com>
> Subject: [SPDK] Access control on the subsystem NQN
> 
> Hi,
> 
> On a previous thread, I got the great answer that a subsystem is actually an
> access control list.
> We have been using it as such, but some of the behavior seems odd.
> 
> On host_remove the sessions to the hosts are not disconnected, this means that
> even though I removed the host from the ACL, it will have access, until it
> disconnects (although it cannot connect another session).
> In addition, a host can see all the subsystems exposed on the IP, even though it
> has access to only some of them.
> 
> We would be happy to work on these issues, but I would like to understand the
> expected behavior.
> 
> Thanks,
> Shahar
> _______________________________________________
> SPDK mailing list
> SPDK(a)lists.01.org
> https://lists.01.org/mailman/listinfo/spdk
> _______________________________________________
> SPDK mailing list
> SPDK(a)lists.01.org
> https://lists.01.org/mailman/listinfo/spdk