[stgt] [PATCH 1/1] Readonly disk LUNs
ronniesahlberg at gmail.com
Sun Apr 4 10:06:39 CEST 2010
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.
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.
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
# 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
tgtadm --lld iscsi --mode logicalunit --op update --tid 2 --lun 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
Differently from a 9260 or a symm but workable?
You have policy but mechanism is somewhat different.
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
More information about the stgt