On Mon, Feb 5, 2018 at 3:17 PM, Sagi Grimberg <[email protected]> wrote: > >>>> Hi Bart, >>>> >>>> My another 2 cents:) >>>> On Fri, Feb 2, 2018 at 6:05 PM, Bart Van Assche <[email protected]> >>>> wrote: >>>>> >>>>> >>>>> On Fri, 2018-02-02 at 15:08 +0100, Roman Pen wrote: >>>>>> >>>>>> >>>>>> 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? > >> 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?
