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

[Edward Tomasz Napierała]

On 1021T1931, Harald Schmalzbauer wrote:
>  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 think I like the second one better.  Except I'm not sure about
"target-filter" name.  "authorized-targets-only" perhaps?

> 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...

Thought about this as default too.  Question is, wouldn't it confuse
users?  On the other hand, _not_ doing it by default could be confusing
too, just in another way.

I kind of have a prototype for this.  Could you test patches against
11-CURRENT, when I have them ready?

> >> 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).

Ok.

> >> 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 :-(

Ah.  AFAIK it's just a "device name", at SCSI level.  Basically, there
are several kinds of identifiers a SCSI device (accessed over iSCSI
or some other transport) can return when asked.  There is NAA, EUI,
and just text, which I believe is the "scsiname".

> 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.

Hm, yeah, it's a documentation error.  You can only use discovery-auth-group.

> 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 :-)

_Every_ problem is worth reporting.  I've just fixed the spurious
warning, btw.  ;-)

> 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}

What is the above for?

> +
> +     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
> +     }

This is to show ohw "auth-type none" should be used, right?  I like it.

> +
>       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
> +            }
> +     }

This one, however, looks a little redundant.