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 553A58A9EB for ; Fri, 21 Oct 2022 10:07:28 +0200 (CEST) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id 2DF141ED18 for ; Fri, 21 Oct 2022 10:06:58 +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:06:57 +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 611D044AED for ; Fri, 21 Oct 2022 10:06:57 +0200 (CEST) Date: Fri, 21 Oct 2022 10:06:56 +0200 From: Wolfgang Bumiller To: Dominik Csapak Cc: pve-devel@lists.proxmox.com Message-ID: <20221021080656.5ermtpjivpe7izjd@wobu-vie.proxmox.com> References: <20221020131412.3493343-1-d.csapak@proxmox.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20221020131412.3493343-1-d.csapak@proxmox.com> X-SPAM-LEVEL: Spam detection results: 0 AWL 0.247 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: Re: [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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Oct 2022 08:07:28 -0000 On Thu, Oct 20, 2022 at 03:14:09PM +0200, Dominik Csapak wrote: > 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..) I think it makes sense. Eg. you may not want to expose ssh access publicly but need the UI - then at least root could access the shell over the UI to fix stuff, while for other users we can never be sure they're actually still valid. Although we could argue @pam users should be allowed to login as well, since those are machine-local after all? But as far as I'm concerned, even root@pam-only for non-quorate nodes would make enough sense.