[stgt] [PATCH 1/1] Readonly disk LUNs

[ronnie sahlberg]

On Sun, Apr 4, 2010 at 5:39 PM, FUJITA Tomonori
<fujita.tomonori at lab.ntt.co.jp> wrote:
> On Sun, 4 Apr 2010 08:50:54 +1000
> ronnie sahlberg <ronniesahlberg at gmail.com> wrote:
>
>> There was a few minor details that would require re-working in my patch.
>> For example "leaking" devicespecific code out into the spc
>> mode-sense6/10 commands
>> that would have to be done slightly differently.
>
> Just make sure that we all are on the same page. His requirement is
> more complicated than your patch; read-only attribute "on
> per-initiator basis". Probably, we need to extend the current security
> model, all-or-nothing on per-initiator basis if we really want this.
>

True.

For many dedicated HW platforms, you have one single taget that
represents the entire device  and then using per LUN ACL rules to do
remapping of LUN numbers on a per initiator basis or similar.
That is when you often have per initiator ro mappings and even per
initiator lun number remappings.



Software based targets like TGTD often have the possibility to create
unlimited number of targets and thus can solve the same issue by
target-level ACLs instead of per lun/initiator ACLs.



Craig,
While not exactly as you are used to in what I assume are HW based
iscsi boxens, instead of having readwrite/readonly settings based on
the initiator level, would this be acceptable to your problem space ?


You create TWO targets,   iqn.2010-04:readwrite and iqn.2010-04:readonly.
On both these two targerts you create a LUN that uses the same backing
store. I.e. two targets bot both use the same physical LUN.
On the readonly target you flag this LUN as reaonly.


Now you then use targetlevel ACLs and allow only readwrite initiators
to access the readwrite target   but not the readonly target.
You also use ALCs to make sure readonly initiators can only access the
readonly target but not the readwrite target.



I.e.   difference in mechanism   but policy still available. On target
lever instead of per lun acl level.



Something like this:

# create readwrite target and lumn
tgtadm --lld iscsi --mode target --op new --tid 1 -T iqn.2010-03:readwrite
tgtadm --lld iscsi --mode logicalunit --op new --tid 1 --lun 1 -b
/backend-disk.img

# create a second target that is readonly but exports the same backing store
tgtadm --lld iscsi --mode target --op new --tid 2 -T iqn.2010-03:readonly
tgtadm --lld iscsi --mode logicalunit --op new --tid 2 --lun 1 -b
/backend-disk.img
tgtadm --lld iscsi --mode logicalunit --op update --tid 2 --lun 1
--params readonly=1


Now, two targets, exporting the same file   you can now use ACLs on
target 1 and 2 to control which initiator gets rw and ro access to the
lun.



Differently from a 9260 or a symm  but workable?

You have policy but mechanism is somewhat different.


regards
ronnie sahlberg




regards
ronnie sahlberg
--
To unsubscribe from this list: send the line "unsubscribe stgt" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html