From: Danil Kipnis <danil.kipnis@profitbricks.com>
To: Sagi Grimberg <sagi@grimberg.me>
Cc: Jinpu Wang <jinpu.wang@profitbricks.com>,
Bart Van Assche <Bart.VanAssche@wdc.com>,
"roman.penyaev@profitbricks.com" <roman.penyaev@profitbricks.com>,
"linux-block@vger.kernel.org" <linux-block@vger.kernel.org>,
"linux-rdma@vger.kernel.org" <linux-rdma@vger.kernel.org>,
"hch@infradead.org" <hch@infradead.org>,
"ogerlitz@mellanox.com" <ogerlitz@mellanox.com>,
"axboe@kernel.dk" <axboe@kernel.dk>
Subject: Re: [PATCH 00/24] InfiniBand Transport (IBTRS) and Network Block Device (IBNBD)
Date: Mon, 5 Feb 2018 17:40:23 +0100 [thread overview]
Message-ID: <CAHg0HuxtvRvPcX8yZxcwSSP5XK6ZnLbxBkpx+X7QyDZtny3XZA@mail.gmail.com> (raw)
In-Reply-To: <41347a8d-8a3b-c35f-801c-b4b21c37f285@grimberg.me>
On Mon, Feb 5, 2018 at 3:17 PM, Sagi Grimberg <sagi@grimberg.me> wrote:
>
>>>> Hi Bart,
>>>>
>>>> My another 2 cents:)
>>>> On Fri, Feb 2, 2018 at 6:05 PM, Bart Van Assche <Bart.VanAssche@wdc.com>
>>>> 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?
next prev parent reply other threads:[~2018-02-05 16:40 UTC|newest]
Thread overview: 79+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-02-02 14:08 [PATCH 00/24] InfiniBand Transport (IBTRS) and Network Block Device (IBNBD) Roman Pen
2018-02-02 14:08 ` [PATCH 01/24] ibtrs: public interface header to establish RDMA connections Roman Pen
2018-02-02 14:08 ` [PATCH 02/24] ibtrs: private headers with IBTRS protocol structs and helpers Roman Pen
2018-02-02 14:08 ` [PATCH 03/24] ibtrs: core: lib functions shared between client and server modules Roman Pen
2018-02-05 10:52 ` Sagi Grimberg
2018-02-06 12:01 ` Roman Penyaev
2018-02-06 16:10 ` Jason Gunthorpe
2018-02-07 10:34 ` Roman Penyaev
2018-02-02 14:08 ` [PATCH 04/24] ibtrs: client: private header with client structs and functions Roman Pen
2018-02-05 10:59 ` Sagi Grimberg
2018-02-06 12:23 ` Roman Penyaev
2018-02-02 14:08 ` [PATCH 05/24] ibtrs: client: main functionality Roman Pen
2018-02-02 16:54 ` Bart Van Assche
2018-02-05 13:27 ` Roman Penyaev
2018-02-05 14:14 ` Sagi Grimberg
2018-02-05 17:05 ` Roman Penyaev
2018-02-05 11:19 ` Sagi Grimberg
2018-02-05 14:19 ` Roman Penyaev
2018-02-05 16:24 ` Bart Van Assche
2018-02-02 14:08 ` [PATCH 06/24] ibtrs: client: statistics functions Roman Pen
2018-02-02 14:08 ` [PATCH 07/24] ibtrs: client: sysfs interface functions Roman Pen
2018-02-05 11:20 ` Sagi Grimberg
2018-02-06 12:28 ` Roman Penyaev
2018-02-02 14:08 ` [PATCH 08/24] ibtrs: server: private header with server structs and functions Roman Pen
2018-02-02 14:08 ` [PATCH 09/24] ibtrs: server: main functionality Roman Pen
2018-02-05 11:29 ` Sagi Grimberg
2018-02-06 12:46 ` Roman Penyaev
2018-02-02 14:08 ` [PATCH 10/24] ibtrs: server: statistics functions Roman Pen
2018-02-02 14:08 ` [PATCH 11/24] ibtrs: server: sysfs interface functions Roman Pen
2018-02-02 14:08 ` [PATCH 12/24] ibtrs: include client and server modules into kernel compilation Roman Pen
2018-02-02 14:08 ` [PATCH 13/24] ibtrs: a bit of documentation Roman Pen
2018-02-02 14:08 ` [PATCH 14/24] ibnbd: private headers with IBNBD protocol structs and helpers Roman Pen
2018-02-02 14:08 ` [PATCH 15/24] ibnbd: client: private header with client structs and functions Roman Pen
2018-02-02 14:08 ` [PATCH 16/24] ibnbd: client: main functionality Roman Pen
2018-02-02 15:11 ` Jens Axboe
2018-02-05 12:54 ` Roman Penyaev
2018-02-02 14:08 ` [PATCH 17/24] ibnbd: client: sysfs interface functions Roman Pen
2018-02-02 14:08 ` [PATCH 18/24] ibnbd: server: private header with server structs and functions Roman Pen
2018-02-02 14:08 ` [PATCH 19/24] ibnbd: server: main functionality Roman Pen
2018-02-02 14:09 ` [PATCH 20/24] ibnbd: server: functionality for IO submission to file or block dev Roman Pen
2018-02-02 14:09 ` [PATCH 21/24] ibnbd: server: sysfs interface functions Roman Pen
2018-02-02 14:09 ` [PATCH 22/24] ibnbd: include client and server modules into kernel compilation Roman Pen
2018-02-02 14:09 ` [PATCH 23/24] ibnbd: a bit of documentation Roman Pen
2018-02-02 15:55 ` Bart Van Assche
2018-02-05 13:03 ` Roman Penyaev
2018-02-05 14:16 ` Sagi Grimberg
2018-02-02 14:09 ` [PATCH 24/24] MAINTAINERS: Add maintainer for IBNBD/IBTRS modules Roman Pen
2018-02-02 16:07 ` [PATCH 00/24] InfiniBand Transport (IBTRS) and Network Block Device (IBNBD) Bart Van Assche
2018-02-02 16:40 ` Doug Ledford
2018-02-05 8:45 ` Jinpu Wang
2018-06-04 12:14 ` Danil Kipnis
2018-02-02 17:05 ` Bart Van Assche
2018-02-05 8:56 ` Jinpu Wang
2018-02-05 11:36 ` Sagi Grimberg
2018-02-05 13:38 ` Danil Kipnis
2018-02-05 14:17 ` Sagi Grimberg
2018-02-05 16:40 ` Danil Kipnis [this message]
2018-02-05 18:38 ` Bart Van Assche
2018-02-06 9:44 ` Danil Kipnis
2018-02-06 15:35 ` Bart Van Assche
2018-02-05 16:16 ` Bart Van Assche
2018-02-05 16:36 ` Jinpu Wang
2018-02-07 16:35 ` Christopher Lameter
2018-02-07 17:18 ` Roman Penyaev
2018-02-07 17:32 ` Bart Van Assche
2018-02-08 17:38 ` Danil Kipnis
2018-02-08 18:09 ` Bart Van Assche
2018-06-04 12:27 ` Danil Kipnis
2018-02-05 12:16 ` Sagi Grimberg
2018-02-05 12:30 ` Sagi Grimberg
2018-02-07 13:06 ` Roman Penyaev
2018-02-05 16:58 ` Bart Van Assche
2018-02-05 17:16 ` Roman Penyaev
2018-02-05 17:20 ` Bart Van Assche
2018-02-06 11:47 ` Roman Penyaev
2018-02-06 13:12 ` Roman Penyaev
2018-02-06 16:01 ` Bart Van Assche
2018-02-07 12:57 ` Roman Penyaev
2018-02-07 16:35 ` Bart Van Assche
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAHg0HuxtvRvPcX8yZxcwSSP5XK6ZnLbxBkpx+X7QyDZtny3XZA@mail.gmail.com \
--to=danil.kipnis@profitbricks.com \
--cc=Bart.VanAssche@wdc.com \
--cc=axboe@kernel.dk \
--cc=hch@infradead.org \
--cc=jinpu.wang@profitbricks.com \
--cc=linux-block@vger.kernel.org \
--cc=linux-rdma@vger.kernel.org \
--cc=ogerlitz@mellanox.com \
--cc=roman.penyaev@profitbricks.com \
--cc=sagi@grimberg.me \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).