netdev - Re: [PATCH] Don't allow multiple TPGs or targets to share a portal

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 18 Feb 2013 14:41:09 -0800
From:	Andy Grover <agrover@...hat.com>
To:	"Nicholas A. Bellinger" <nab@...ux-iscsi.org>
CC:	target-devel@...r.kernel.org, netdev@...r.kernel.org
Subject: Re: [PATCH] Don't allow multiple TPGs or targets to share a portal

On 02/15/2013 07:46 AM, Nicholas A. Bellinger wrote:
> The wording in section Section 3.4.1, e) that your referring to:
>
> "Each Network Portal, as utilized by a given iSCSI Node, belongs to
> exactly one portal group within that node."
>
> does not mean that individual network portals are limited to a single
> network entity, but that network portals are linked to a single TPG
> within an individual TargetName.  Eg, 'that node' does not mean the
> entire physical machine (network entity), that may contain multiple
> nodes (TargetName+TargetPortalGroupTag endpoints).
>
> However, in practice I've not yet seen a target implementation that
> supports multiple TPGs actually enforce this, considering this is not
> accompanied by a "SHOULD not" or "MUST not" anywhere in the spec.  So
> unless you have a specific problem case where this is causing an issue
> with an initiator, I'm likely not going to accept a kernel patch to
> change existing behavior.

OK, so I'm clear now that a NetworkPortal can be shared among 
TargetNames, but not among TPGs within a TargetName.

But LIO currently allows it.
See https://bugzilla.redhat.com/show_bug.cgi?id=908368 .

The tester's actual issue may not be related to this area, but if you 
look at the attachment in comment 2, this configuration was allowed.

I don't think this is an issue where we need to worry about existing 
behavior. This *can't* work because the initiator passes the desired 
TargetName during iSCSI login, but not TargetPortalGroupTag. There's no 
way a target can tell which TPG the initiator wants if the TargetName 
for two are the same.

We could add a check for this to the rtslib userspace library, but this 
would mean the kernel could still be configured this way, if rtslib was 
not used to wrap configfs accesses. Therefore I'd push for the kernel to 
check for this. Would a patch for that fly?

Thanks -- Regards -- Andy

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