From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <d.csapak@proxmox.com>
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 121488A73C
for <pve-devel@lists.proxmox.com>; Thu, 20 Oct 2022 15:14:45 +0200 (CEST)
Received: from firstgate.proxmox.com (localhost [127.0.0.1])
by firstgate.proxmox.com (Proxmox) with ESMTP id E5F4A181D6
for <pve-devel@lists.proxmox.com>; Thu, 20 Oct 2022 15:14:14 +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 <pve-devel@lists.proxmox.com>; Thu, 20 Oct 2022 15:14:13 +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 4380844AC9
for <pve-devel@lists.proxmox.com>; Thu, 20 Oct 2022 15:14:13 +0200 (CEST)
From: Dominik Csapak <d.csapak@proxmox.com>
To: pve-devel@lists.proxmox.com
Date: Thu, 20 Oct 2022 15:14:09 +0200
Message-Id: <20221020131412.3493343-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.068 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
Subject: [pve-devel] [PATCH access-control 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 <pve-devel.lists.proxmox.com>
List-Unsubscribe: <https://lists.proxmox.com/cgi-bin/mailman/options/pve-devel>,
<mailto:pve-devel-request@lists.proxmox.com?subject=unsubscribe>
List-Archive: <http://lists.proxmox.com/pipermail/pve-devel/>
List-Post: <mailto:pve-devel@lists.proxmox.com>
List-Help: <mailto:pve-devel-request@lists.proxmox.com?subject=help>
List-Subscribe: <https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel>,
<mailto:pve-devel-request@lists.proxmox.com?subject=subscribe>
X-List-Received-Date: Thu, 20 Oct 2022 13:14:45 -0000
intended as a replacement for my previous patch: [0]
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
an alternative approach to this would be to implement a 'needs save'
check in rust and call that with the tfa-response, but we can still do
that later
patches 2 and 3 are debatable, but i found it makes the code a bit clearer
my suggestion for the 'let users not login in non-quorate cluster' would
be to maybe add a flag to the users that must be explicitely enabled
for them to login, so that e.g. some admin users can always login, but
normal users cannot (i got no real feedback on that idea in the
conversation of the last version of this sadly..)
0: https://lists.proxmox.com/pipermail/pve-devel/2022-September/053939.html
Dominik Csapak (3):
authenticate_2nd_new: only lock tfa config for recovery keys
authenticate_2nd_new: rename $otp to $tfa_response
authenticate_user: don't give empty $tfa_challenge to
authenticate_2nd_new
src/PVE/AccessControl.pm | 131 +++++++++++++++++++++------------------
1 file changed, 71 insertions(+), 60 deletions(-)
--
2.30.2