Date: Wed, 22 Oct 2014 14:30:26 +0200 From: Harald Schmalzbauer <h.schmalzbauer@omnilan.de> To: FreeBSD Stable <freebsd-stable@freebsd.org> Subject: Re: ctld(8), multiple 'portal-group' on same socket (individual 'discovery-auth-group' restrictions) Message-ID: <5447A362.30605@omnilan.de> In-Reply-To: <20141022105804.GB5415@brick.home> References: <5444C94C.4050705@omnilan.de> <20141021104308.GA5990@brick.home> <54464405.4090207@omnilan.de> <20141021134516.GA89872@brick.home> <5446988B.5020509@omnilan.de> <20141022105804.GB5415@brick.home>
next in thread | previous in thread | raw e-mail | index | archive | help
This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enigB720318A32A5BEBD0BE97B3E
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Bez=C3=BCglich Edward Tomasz Napiera=C5=82a's Nachricht vom 22.10.2014 1=
2:58
(localtime):
> On 1021T1931, Harald Schmalzbauer wrote:
>> Bez=C3=BCglich Edward Tomasz Napiera=C5=82a's Nachricht vom 21.10.201=
4 15:45
>> (localtime):
>>
>> =E2=80=A6
>>>> 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 w=
ho
>>>> else was granted this extra resource (by definition, there's no priv=
ate
>>>> data on the clients which use that backup-strategy, so no need for
>>>> qualified identity checks or encryption needed). Even with any secur=
ity
>>>> mechanisms active, two consumers (some dozen in my case) of the same=
>>>> portal know about the other. That's one example where this feature w=
as
>>>> useful for me.
>>> So basically, each target has a different user/password pair, and
>>> during discovery the target only returns those targets that can actua=
lly
>>> 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 targe=
t
>> 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=
=2E
>> =E2=80=A6 }
>>
>> 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
>> =E2=80=A6 }
> I think I like the second one better. Except I'm not sure about
> "target-filter" name. "authorized-targets-only" perhaps?
"authorized-targets-only" is much better!
My idea was to have both options available.
The option in the portal-group Context allowes to control if the option
in the target Context should have effect at all (thus could save
executions of unwanted checks).
And the target option could override the meaning of
"authorized-targets-only" when "SendTarget" set to "on-discover".
But perhaps that's more confusing than useful=E2=80=A6 One imaginable use=
case
was if the target-portal admin want's to draw attention to a distinct
offered taget, regardless if the intitiator's admin has access _yet_ (so
even if the target-portal does filtering, that special target could be
sent to the initiator, who probably wants to get that target).
Basically I wanted to suggest something least radical as possible, so
one could restore "old" behaviour as easy as possible.
But I agree if you think that's too much overhead for such a special case=
=2E
>> 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 discove=
ry:
>> =C2=BBThe goal of iSCSI discovery is to allow an initiator to find=
the
>> targets to which it has access, =E2=80=A6=C2=AB
>>
>> =E2=80=9C=E2=80=A6 to which it has access=E2=80=9D sounds to me like t=
he 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.
Can't estimate what was more confusing.
I think I remember having seen (enterprise) SAN devices from leading
manufactureres, which also didn't filter.
But if ESXi is used as initiator, the operator nevertheless wouldn't get
confused, since she sees auto-attached targets in the first place, which
"feels" like a filtered result.
I don't know if ESXi admins commonly look at the real discovery-result-li=
st.
But that's what all windows operators get presented at first place=E2=80=A6=
For me personally, I was very suprised when I first saw targets which I
don't have access to and my first idea was to ask the admin of the SAN
device, if he accidentally has switched off anything=E2=80=A6
> I kind of have a prototype for this. Could you test patches against
> 11-CURRENT, when I have them ready?
It's my pleasure to test anything! But I only have one workstation with
11-current available. So I'm limited to synthetic tests and won't be
able to provide real world experience with 11. But if the changesets are
also applicable to stable (with cosmetic changes, which I can do
myself), I can do tests in my small (productive) office environment
(consisting of only one ESXi and two Windows initiators), so at least
little real world testing :-)
>> 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
>> =20
>> + # buitlin special
>> + #auth-group default { auth-type deny }
>> + #auth-group no-authentication { auth-type none}
> What is the above for?
I thought it was useful for lazy people like me, to get the idea of
"auth-group no-authentication" in the existing example, without reading :=
-)
It should show that there are two built-in default auth-groups (or at
least that the result is like if they were defined like that).
And that there is 'auth-type'
=20
>> +
>> + target iqn.2012-06.com.example:target1 {
>> + auth-type none
>> + initiator-name "iqn.2012-06.com.example:initiatorhostname=
0"
>> + initiator-portal [2001:DB8::de:ef]
>> + portal-group example2
>> + lun 0 {
>> + path /dev/zvol/example_1
>> + }
>> + }
> This one, however, looks a little redundant.
Yes, it's mostly the other examples duplicated, but there's the very
important 'auth-type' shown in action. Maybe there's a better way to
show it, or maybe it's enough to show it in my other suggested
auth-group example.
Thanks,
-Harry
--------------enigB720318A32A5BEBD0BE97B3E
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.18 (FreeBSD)
iEYEARECAAYFAlRHo2IACgkQLDqVQ9VXb8iEEQCfZ2iLclg9Z2cOJpmLs0tVRbMr
LHEAn2yjqen8+V2o5bSf2jElIBV7uB21
=8FXf
-----END PGP SIGNATURE-----
--------------enigB720318A32A5BEBD0BE97B3E--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5447A362.30605>