From mboxrd@z Thu Jan 1 00:00:00 1970 Content-Type: multipart/mixed; boundary="===============3566961267920915042==" MIME-Version: 1.0 From: Howell, Seth Subject: Re: [SPDK] Access control on the subsystem NQN Date: Mon, 07 Jan 2019 17:36:23 +0000 Message-ID: In-Reply-To: AM6PR04MB5127CEEE6588A62ED9254CC489B20@AM6PR04MB5127.eurprd04.prod.outlook.com List-ID: To: spdk@lists.01.org --===============3566961267920915042== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Hi Shahar, These are great questions! The first one I am just answering intuitively, I think that if a host is re= moved from from the subsystem whitelist, all of its connections should be d= ropped. I can't think of an instance where we would want an unauthorized ho= st 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 determ= ine 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 a= ccessible to the host; . . . " This quote makes it sound to me that if a host is not allowed to access a n= amespace, 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. = Something to think about is that we are planning to add (NVMe in-band) auth= entication 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 h= osts 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 Cc: Eyal Shnitzer Subject: [SPDK] Access control on the subsystem NQN Hi, On a previous thread, I got the great answer that a subsystem is actually a= n 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 t= hat 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 thou= gh it has access to only some of them. We would be happy to work on these issues, but I would like to understand t= he expected behavior. Thanks, Shahar _______________________________________________ SPDK mailing list SPDK(a)lists.01.org https://lists.01.org/mailman/listinfo/spdk --===============3566961267920915042==--