From mboxrd@z Thu Jan 1 00:00:00 1970 Content-Type: multipart/mixed; boundary="===============5400535308401367055==" MIME-Version: 1.0 From: Shahar Salzman Subject: Re: [SPDK] Access control on the subsystem NQN Date: Wed, 09 Jan 2019 14:45:26 +0000 Message-ID: In-Reply-To: 37B08312E007AE46A00101F43DA919DDE5345EED@FMSMSX105.amr.corp.intel.com List-ID: To: spdk@lists.01.org --===============5400535308401367055== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Great to hear this. Not sure when we will get to working on these issues, but we will definitel= y put some work into them. I believe that removing the connection on ns_remove takes priority between = the two issues. We will update when we start working on it. Should this go into trello as a task? Or should I open bugs on github? ________________________________ From: SPDK on behalf of Walker, Benjamin Sent: Tuesday, January 8, 2019 5:06 PM To: Storage Performance Development Kit Cc: Eyal Shnitzer Subject: Re: [SPDK] Access control on the subsystem NQN > -----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 > Cc: Eyal Shnitzer > 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 capabili= ties: > 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 mak= es > a discovery request. > I will defer to Ben if he wants to shoot me down on this, but I think tha= t if you > want to close all of the connections between a subsystem and a host is re= moved > from its ACL, and change the way the discovery service works. I concur. These are both bugs - the connections should drop and the subsyst= em should not show up in the discovery log if the host does not have access/loses access to the s= ubsystem. > > 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 investigatin= g 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 Salzm= an > 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= 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 th= ough 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 _______________________________________________ SPDK mailing list SPDK(a)lists.01.org https://lists.01.org/mailman/listinfo/spdk --===============5400535308401367055==--