On Mon, Feb 5, 2018 at 5:16 PM, Bart Van Assche <Bart.VanAssche@xxxxxxx> wrote: > On Mon, 2018-02-05 at 09:56 +0100, Jinpu Wang wrote: >> Hi Bart, >> >> My another 2 cents:) >> On Fri, Feb 2, 2018 at 6:05 PM, Bart Van Assche <Bart.VanAssche@xxxxxxx> 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. On server side, admin can set the dev_search_path in >> module parameter to set parent directory, this will concatenate with the path >> client send in open message to open a block device. > > Hello Jack, > > That approach may work well for your employer but sorry I don't think this is > sufficient for an upstream driver. I think that most users who configure a > network storage target expect full control over which storage devices are exported > and also over which clients do have and do not have access. > > Bart. Hello Bart, I agree for general purpose, it may be good to have better access control. Thanks, -- Jack Wang Linux Kernel Developer -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
