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