ctld(8), multiple 'portal-group' on same socket (individual 'discovery-auth-group' restrictions)

[Harald Schmalzbauer]

 Bezüglich Edward Tomasz Napierała's Nachricht vom 21.10.2014 15:45
(localtime):

…
>> In my "real world" case, I dispense backup disks to win7 clients via iSCSI.
>> I liked the possibility to limit target-discovery-results, because
>> curious people, garnated such extra resources, weren't able to see who
>> else was granted this extra resource (by definition, there's no private
>> data on the clients which use that backup-strategy, so no need for
>> qualified identity checks or encryption needed). Even with any security
>> mechanisms active, two consumers (some dozen in my case) of the same
>> portal know about the other. That's one example where this feature was
>> useful for me.
> So basically, each target has a different user/password pair, and
> during discovery the target only returns those targets that can actually
> be accessed using that user/password?

In general, yes, that's what I did with istgt. But I omitted chap
authentication, intead I'm just checking initiator-name/adress.
So speaking in ctl.conf, I would love to see an extension in the target
Context, which influences discovering results, maybe like

target iqn.2012-06.com.example:target0 {
  SendTarget on-discover | access-granted # access-granted only has
effect on assigned portal-group(s), which have 'target-filter' enabled.
  … }

I guess that would need quiet a lot of extra checks added to existing
discovery-response functions, so maybe it would make sense to
selectively enable/disbale this extra check at portal-group Context in
the first place, maybe like

portal-group lan0 {
  target-filter on | off
  … }


I just had a look at rfc3721, to find a suitable name for the
'SendTarget' config option I suggested here
(http://www.ietf.org/rfc/rfc3721.txt, Page 12, 3.b).

Quote of the first sentence in chapter 3, describing the iSCSI discovery:
    »The goal of iSCSI discovery is to allow an initiator to find the
targets to which it has access, …«

“… to which it has access” sounds to me like the filtered SendTarget
behaviuor should be default, but I haven't read the complete docuemtn
nor am I native english speaker...


>> Another one actually is (since not implemented in ctld, yet?) with
>> virtual DVDs. If you provide 50 DVDs at one portal, it's confusing if
>> any initiator needs to select from the complete list.
> In this case do the returned targets depend on authentication, or something
> else, eg. a static list defined in config?

The returned targets are still access restricted, by authentication or
any initiator-match rule (name, address, both).


>> I'd like to point to two options I'm missing:
>> option RPM
>> option FormFactor
>> And another one I don't know/understand:
>> option scsiname
>>
>> Missing resp. wrong reported option RPM leads to identification as SSD
>> with ESXi initiators. I don't remember what defines a SSD vs. HDD, I
>> think it was a threshold of something about 400? Or was it 0? I think I
>> read the former… Don't have docs handy.
>> The FormFactor was more cosmetic, but in bigger environments I guess it
>> can be useful if you have multiple targets available, choosing the
>> better fitting backend-pool e.g.
> Hm, ok.

Thanks for your attention again!


>> If someone could point me to the meaning of option iscsiname?
> That's an istgt option, right?

Sorry, haven't made clear: ctl.conf(5) references ctladm(8) for possible
"name value" pairs for the "option" option in the target Context.
In ctladm's OPTIONS section, I can find most options I ever used (and in
my case mandatory options like "product") besides to above mentioned two
(RPM and FormFactor), and also some additional I haven't used.
There's "scsiname" listed. I don't even understand the meaning of that :-(


Hope you don't mind if I add another question:

In ctl.conf(5), section "portal-group Context", under the description
for 'discovery-auth-group', one can read:
    »By default, portal groups that do not specify their own auth
settings, using clauses such as chap or initiator-name, are assigned
predefined auth-group "default",…«
I tried to define 'initiator-name' under portal-group Context, but that
didn't work. I think I got an error message and config-reload was rejected.

The reason I tried to not use a predefined auth-froup was, that I get a
warning it I define a auth-group and don't assign it to any target,
instead using it as 'discovery-auth-group' only. Not really a problem,
prpbably not even worth a PR/bugzilla report, but wanted to mention it
here :-)

And, not enough yet, I'd like to suggest a extension to the examples
section of ctl.conf(5):

--- /tmp/ctl.conf.sample.orig   2014-10-21 19:11:46.000000000 +0200
+++ /tmp/ctl.conf.sample        2014-10-21 19:25:28.000000000 +0200
@@ -1,5 +1,16 @@
      pidfile /var/run/ctld.pid
 
+     # buitlin special
+     #auth-group default { auth-type deny }
+     #auth-group no-authentication { auth-type none}
+
+     auth-group        example1 {
+            auth-type none
+            initiator-name "iqn.2012-06.com.example:initiatorhost1"
+            initiator-name "iqn.2012-06.com.example:initiatorhost2"
+            initiator-portal 192.0.2.0/24
+     }
+
      auth-group        example2 {
             chap-mutual "user" "secret" "mutualuser" "mutualsecret"
             chap-mutual "user2" "secret2" "mutualuser" "mutualsecret"
@@ -41,3 +52,13 @@
                     option foo bar
             }
      }
+
+     target iqn.2012-06.com.example:target1 {
+            auth-type none
+            initiator-name "iqn.2012-06.com.example:initiatorhostname0"
+            initiator-portal [2001:DB8::de:ef]
+            portal-group example2
+            lun 0 {
+                    path /dev/zvol/example_1
+            }
+     }


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 196 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20141021/78799099/attachment.sig>