On Mon, Feb 5, 2018 at 3:17 PM, Sagi Grimberg [off-list ref] wrote:

quoted

quoted

quoted

Hi Bart,

My another 2 cents:)
On Fri, Feb 2, 2018 at 6:05 PM, Bart Van Assche [off-list ref]
wrote:

quoted

On Fri, 2018-02-02 at 15:08 +0100, Roman Pen wrote:

quoted

o Simple configuration of IBNBD:
     - Server side is completely passive: volumes do not need to be
       explicitly exported.

That sounds like a security hole? I think the ability to configure
whether or
not an initiator is allowed to log in is essential and also which
volumes
an
initiator has access to.

Our design target for well controlled production environment, so
security is handle in other layer.

What will happen to a new adopter of the code you are contributing?

Hi Sagi, Hi Bart,
thanks for your feedback.
We considered the "storage cluster" setup, where each ibnbd client has
access to each ibnbd server. Each ibnbd server manages devices under
his "dev_search_path" and can provide access to them to any ibnbd
client in the network.

I don't understand how that helps?

quoted

On top of that Ibnbd server has an additional
"artificial" restriction, that a device can be mapped in writable-mode
by only one client at once.

I think one would still need the option to disallow readable export as
well.

It just occurred to me, that we could easily extend the interface in
such a way that each client (i.e. each session) would have on server
side her own directory with the devices it can access. I.e. instead of
just "dev_search_path" per server, any client would be able to only
access devices under <dev_search_path>/session_name. (session name
must already be generated by each client in a unique way). This way
one could have an explicit control over which devices can be accessed
by which clients. Do you think that would do it?