From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from firstgate.proxmox.com (firstgate.proxmox.com [212.224.123.68]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by lists.proxmox.com (Postfix) with ESMTPS id 818E08AB09 for ; Fri, 21 Oct 2022 10:31:49 +0200 (CEST) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id 63CA41F02A for ; Fri, 21 Oct 2022 10:31:19 +0200 (CEST) Received: from proxmox-new.maurer-it.com (proxmox-new.maurer-it.com [94.136.29.106]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by firstgate.proxmox.com (Proxmox) with ESMTPS for ; Fri, 21 Oct 2022 10:31:18 +0200 (CEST) Received: from proxmox-new.maurer-it.com (localhost.localdomain [127.0.0.1]) by proxmox-new.maurer-it.com (Proxmox) with ESMTP id C94CD44B04 for ; Fri, 21 Oct 2022 10:31:17 +0200 (CEST) From: Dominik Csapak To: pve-devel@lists.proxmox.com Date: Fri, 21 Oct 2022 10:31:14 +0200 Message-Id: <20221021083117.1239396-1-d.csapak@proxmox.com> X-Mailer: git-send-email 2.30.2 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-SPAM-LEVEL: Spam detection results: 0 AWL 0.067 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record SPF_PASS -0.001 SPF: sender matches SPF record URIBL_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to URIBL was blocked. See http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block for more information. [accesscontrol.pm] Subject: [pve-devel] [PATCH access-control v2 0/3] improve tfa config locking X-BeenThere: pve-devel@lists.proxmox.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: Proxmox VE development discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Oct 2022 08:31:49 -0000 while we may not want users to login into a non-quorate cluster, preventing it as a side-effect of locking the tfa config is wrong. currently there is only one situation where we actually need to lock the tfa config, namely when using recovery keys, since they have to be removed from it. so this series changes the tfa code in pve so that we only lock when the tfa response is a recovery key changes from v1: * fix wrong regex * pass undef explicitely instead of omitting the parameter * this time tested in both directions: user without tfa can login in quorate & non-quorate cluster user with non-recovery tfa can login in quorate & non-quorate cluster user with recovery tfa can only login in quorate cluser Dominik Csapak (3): authenticate_2nd_new: only lock tfa config for recovery keys authenticate_2nd_new: rename $otp to $tfa_response authenticate_user: pass undef instead of empty $tfa_challenge to authenticate_2nd_new src/PVE/AccessControl.pm | 131 +++++++++++++++++++++------------------ 1 file changed, 71 insertions(+), 60 deletions(-) -- 2.30.2