[SPDK] Updating discovery for ACL

[SPDK] Updating discovery for ACL

[Shahar Salzman]

[-- Attachment #1: Type: text/plain, Size: 706 bytes --]

Hi,

I am following up on bug # 576 - nvme discover shows all target subsystems, even those that are not accessible by the host.

I looked at the discovery subsystem code, and it seems that a good option would be to copy only the relevant part of the discovery log page (i.e. only information about subsystems that the host has access to).
The problem is, that on the discover request there is no hostnqn information,

Looking at the connect, I see that the hostnqn is checked, but not saved anywhere, so it looks like a good option to save it on the controller, so that we can later reference this value.

Now upon discovery we can copy the relevant portions of the log page.

WDYT?

Shahar

Re: [SPDK] Updating discovery for ACL

[Shahar Salzman]

[-- Attachment #1: Type: text/plain, Size: 3528 bytes --]

I started sketching up the implementation yesterday, and am contemplating two directions.

The first is to malloc a jump buffer the size of the already existing discovery log page, and then copy the relevant part of the discovery log page.
The other direction is to use the existing log page, and only copy the relevant subsystem information to the iovec.

The additional caveat is that in either case, the numrec needs to be updated to the filtered number of subsystems.

The first adds a malloc/free on every discovery, the second is much more complicated in that we need to save the iovec_offset and handle all sorts of gnarly corner cases.

Regarding getting the subsystems, I was actually thinking of a "softer" mechanism such as saving, along with the discovery log page an ordered mapping between subsystem and nqn, so when copying the "relevant" part we can do:

for (i = 0; i < subsys_map->num_subsystems; i++) {
        if (!spdk_nvmf_subsystem_host_allowed(subsys_map->subsystems[i], hostnqn) {
                continue;
        }
        /* copy listener info to the jump buffer */
}

________________________________
From: SPDK <spdk-bounces(a)lists.01.org> on behalf of Howell, Seth <seth.howell(a)intel.com>
Sent: Monday, February 25, 2019 8:01 PM
To: Storage Performance Development Kit
Subject: Re: [SPDK] Updating discovery for ACL

Hi Shahar,

I think that placing the hostnqn in the controller is the right thing to do. It will still be accessible from the request object when we do the discovery a few commands later.
When it comes to the actual discovery mechanism, what is your plan? Currently, we only regenerate the discovery log when the generation counter has changed and the log is stored as a collection of strings. We will have to find a way to get back to the subsystems from the log page entries to check access controls.
One would be to regenerate the discovery log every time someone asks for it and check the hostnqn in nvmf_update_discovery_log.
Another way would be to add a new function such as get_nvmf_subsystem_by_nqn to the internal api. That would allow you to loop over the already generated log page buffer and copy over only the allowed entries. I think this way would be more efficient than the first.

Thanks,

Seth

-----Original Message-----
From: SPDK [mailto:spdk-bounces(a)lists.01.org] On Behalf Of Shahar Salzman
Sent: Sunday, February 24, 2019 12:51 PM
To: Storage Performance Development Kit <spdk(a)lists.01.org>
Subject: [SPDK] Updating discovery for ACL

Hi,

I am following up on bug # 576 - nvme discover shows all target subsystems, even those that are not accessible by the host.

I looked at the discovery subsystem code, and it seems that a good option would be to copy only the relevant part of the discovery log page (i.e. only information about subsystems that the host has access to).
The problem is, that on the discover request there is no hostnqn information,

Looking at the connect, I see that the hostnqn is checked, but not saved anywhere, so it looks like a good option to save it on the controller, so that we can later reference this value.

Now upon discovery we can copy the relevant portions of the log page.

WDYT?

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

Re: [SPDK] Updating discovery for ACL

[Howell, Seth]

[-- Attachment #1: Type: text/plain, Size: 2020 bytes --]

Hi Shahar,

I think that placing the hostnqn in the controller is the right thing to do. It will still be accessible from the request object when we do the discovery a few commands later.
When it comes to the actual discovery mechanism, what is your plan? Currently, we only regenerate the discovery log when the generation counter has changed and the log is stored as a collection of strings. We will have to find a way to get back to the subsystems from the log page entries to check access controls.
One would be to regenerate the discovery log every time someone asks for it and check the hostnqn in nvmf_update_discovery_log.
Another way would be to add a new function such as get_nvmf_subsystem_by_nqn to the internal api. That would allow you to loop over the already generated log page buffer and copy over only the allowed entries. I think this way would be more efficient than the first.

Thanks,

Seth

-----Original Message-----
From: SPDK [mailto:spdk-bounces(a)lists.01.org] On Behalf Of Shahar Salzman
Sent: Sunday, February 24, 2019 12:51 PM
To: Storage Performance Development Kit <spdk(a)lists.01.org>
Subject: [SPDK] Updating discovery for ACL

Hi,

I am following up on bug # 576 - nvme discover shows all target subsystems, even those that are not accessible by the host.

I looked at the discovery subsystem code, and it seems that a good option would be to copy only the relevant part of the discovery log page (i.e. only information about subsystems that the host has access to).
The problem is, that on the discover request there is no hostnqn information,

Looking at the connect, I see that the hostnqn is checked, but not saved anywhere, so it looks like a good option to save it on the controller, so that we can later reference this value.

Now upon discovery we can copy the relevant portions of the log page.

WDYT?

Shahar
_______________________________________________
SPDK mailing list
SPDK(a)lists.01.org
https://lists.01.org/mailman/listinfo/spdk