From patchwork Sun Apr 28 04:17:18 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Mike Christie X-Patchwork-Id: 10920633 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id 2A9691398 for ; Sun, 28 Apr 2019 04:17:29 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 196832884A for ; Sun, 28 Apr 2019 04:17:29 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 0C5C5288D0; Sun, 28 Apr 2019 04:17:29 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-7.9 required=2.0 tests=BAYES_00,MAILING_LIST_MULTI, RCVD_IN_DNSWL_HI autolearn=ham version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 6AB432884A for ; Sun, 28 Apr 2019 04:17:26 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1725909AbfD1ERW (ORCPT ); Sun, 28 Apr 2019 00:17:22 -0400 Received: from mx1.redhat.com ([209.132.183.28]:32970 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725818AbfD1ERW (ORCPT ); Sun, 28 Apr 2019 00:17:22 -0400 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 9A21D1440B2; Sun, 28 Apr 2019 04:17:22 +0000 (UTC) Received: from rh2.redhat.com (ovpn-120-174.rdu2.redhat.com [10.10.120.174]) by smtp.corp.redhat.com (Postfix) with ESMTP id CCB3A6B8D6; Sun, 28 Apr 2019 04:17:21 +0000 (UTC) From: Mike Christie To: martin.petersen@oracle.com, linux-scsi@vger.kernel.org, target-devel@vger.kernel.org, nab@linux-iscsi.org Subject: [PATCH 0/2] iscsi target: fix login negotiation Date: Sat, 27 Apr 2019 23:17:18 -0500 Message-Id: <20190428041720.9119-1-mchristi@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.13 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.38]); Sun, 28 Apr 2019 04:17:22 +0000 (UTC) Sender: target-devel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: target-devel@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP The following patches fix login negotiation when the user has disabled authentication, and the initiator is presenting CHAP,None. The problem is that the target initializes AuthMethod to CHAP (normal session) or CHAP,None (discovery session), but when the user does authentication=0/ enforce_discovery_auth=0 we can end up setting AuthMethod to CHAP,None. The user would then have not setup CHAP settings like userid/password since they disabled it, so later the login will fail if the initiator presents CHAP,None, because the target sees CHAP and tries to do that since it had set CHAP,None when disabling auth but there are not valid values. As an alternative to these patches we could also have the configfs file update the AuthMethod when it is written to. For example when userid, password, authentication, enforce_discovery_auth, etc are written to we could update AuthMethod, but I was worried that userspace apps/users could set these in funky orders like initializing the CHAP values then setting authentication/enforce=0 and in that case we might end up not using CHAP when we used to.