From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from firstgate.proxmox.com (firstgate.proxmox.com [IPv6:2a01:7e0:0:424::9]) by lore.proxmox.com (Postfix) with ESMTPS id 845C61FF17E for ; Thu, 13 Nov 2025 17:17:22 +0100 (CET) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id 3F6CD22300; Thu, 13 Nov 2025 17:18:17 +0100 (CET) Message-ID: <4793f1cc-d93a-46f6-b129-f95ee2b3b1ac@proxmox.com> Date: Thu, 13 Nov 2025 17:18:14 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Beta To: Proxmox Datacenter Manager development discussion , Shannon Sterz , =?UTF-8?Q?Fabian_Gr=C3=BCnbichler?= References: <20251106143836.288888-1-s.sterz@proxmox.com> <1763041798.famz3bfta9.astroid@yuna.none> Content-Language: en-US From: Thomas Lamprecht In-Reply-To: X-Bm-Milter-Handled: 55990f41-d878-4baa-be0a-ee34c49e34d2 X-Bm-Transport-Timestamp: 1763050668473 X-SPAM-LEVEL: Spam detection results: 0 AWL -0.024 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DMARC_MISSING 0.1 Missing DMARC policy 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: [pdm-devel] [PATCH datacenter-manager/proxmox/yew-comp v3 00/10] add support for checking acl permissions in (yew) front-ends X-BeenThere: pdm-devel@lists.proxmox.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: Proxmox Datacenter Manager development discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: Proxmox Datacenter Manager development discussion Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: pdm-devel-bounces@lists.proxmox.com Sender: "pdm-devel" Am 13.11.25 um 15:26 schrieb Shannon Sterz: >> high-level question: >> >> the actual privilege checks in the backend use the full set of ACLs. the >> frontend can only ever see a subset of ACLs, since giving it all ACLs >> would leak a lot of sensitive information. >> >> doesn't that mean that the frontend will make wrong decisions in some >> scenarios? >> >> e.g., the backend currently doesn't return any group ACLs if you do >> exact filtering. but group ACLs can influence the ACL resolution > > as discussed off list, that'd be true if the filter in > `extract_acl_node_data` isn't adapted. i'll add a fixme comment to the > next version of this series for now. > > how exactely to takle this will depend on how we implement groups: > > * does a user know that they are part of a group? No general objection, a lot of ACL system work that way, but should not be required. > * if disclosing such membership is fine, is it fine to disclose what the > group has access to in all cases? e.g. what if the user is part of a > group, but certain acl entries are then restricted on top via a > NoAccess privilege or similar? Disclosing access is IMO always fine, that can basically be probed anyway. Where that access comes from does not really matter here. > * will looking up whether the user is part of a group be handled by the > acl tree directly? (this is at least indicated by comments already > present in `AclTreeNode::extract_group_roles()`) Probably, otherwise it would need to get the relevant acl's "injected". > most of these are difficult to answer without actually tackling an > implementation of the group feature. not entirely sure how i can address > this here beside adding that `fixme` comment. Seems OK to me. If we need more changes to make this safe enough for groups we can still change this, be it by adding a new endpoint and deprecating the old one, where the old one would then probably ignores groups for the rest of its existence. One option could then be to have something like the heuristic in PVE but more generic (and maybe we're able to make it a bit easier to understand), but tbh. that isn't exactly perfect either, and so trying this route until we get an actual blocker seems still worthwhile to me. > i suppose i could also try to extract the roles with `AclTree::roles`, > which extracts the roles via `AclTreeNode::extract_roles` which is > already somewhat opinionated about how groups should work here. not sure > what is ideal here. That I did not looked closely enough into to answer for sure. _______________________________________________ pdm-devel mailing list pdm-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pdm-devel