From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from firstgate.proxmox.com (firstgate.proxmox.com [212.224.123.68]) by lore.proxmox.com (Postfix) with ESMTPS id E4FDD1FF15C for ; Fri, 3 Oct 2025 12:10:39 +0200 (CEST) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id D4CFC92D; Fri, 3 Oct 2025 12:10:39 +0200 (CEST) Message-ID: Date: Fri, 3 Oct 2025 12:10:20 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Beta To: Thomas Lamprecht , Proxmox Backup Server development discussion References: <20251003085045.1346864-1-d.csapak@proxmox.com> <20251003085045.1346864-3-d.csapak@proxmox.com> <28f638cf-5e76-4b68-8594-6860a8ea22b5@proxmox.com> Content-Language: en-US From: Dominik Csapak In-Reply-To: <28f638cf-5e76-4b68-8594-6860a8ea22b5@proxmox.com> X-Bm-Milter-Handled: 55990f41-d878-4baa-be0a-ee34c49e34d2 X-Bm-Transport-Timestamp: 1759486212161 X-SPAM-LEVEL: Spam detection results: 0 AWL -0.124 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 POISEN_SPAM_PILL 0.1 Meta: its spam POISEN_SPAM_PILL_1 0.1 random spam to be learned in bayes POISEN_SPAM_PILL_3 0.1 random spam to be learned in bayes RCVD_IN_VALIDITY_CERTIFIED_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to Validity was blocked. See https://knowledge.validity.com/hc/en-us/articles/20961730681243 for more information. RCVD_IN_VALIDITY_RPBL_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to Validity was blocked. See https://knowledge.validity.com/hc/en-us/articles/20961730681243 for more information. RCVD_IN_VALIDITY_SAFE_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to Validity was blocked. See https://knowledge.validity.com/hc/en-us/articles/20961730681243 for more information. SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record SPF_PASS -0.001 SPF: sender matches SPF record Subject: Re: [pbs-devel] [PATCH proxmox-backup 1/6] backup: hierarchy: add new can_access_any_namespace_in_range helper X-BeenThere: pbs-devel@lists.proxmox.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: Proxmox Backup Server development discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: Proxmox Backup Server development discussion Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Errors-To: pbs-devel-bounces@lists.proxmox.com Sender: "pbs-devel" On 10/3/25 11:52 AM, Thomas Lamprecht wrote: > Am 03.10.25 um 10:50 schrieb Dominik Csapak: >> sometimes we need to check the permissions in a range from a starting >> namespace with a certain depth. >> >> Signed-off-by: Dominik Csapak >> --- >> src/backup/hierarchy.rs | 27 ++++++++++++++++++++------- >> 1 file changed, 20 insertions(+), 7 deletions(-) >> >> diff --git a/src/backup/hierarchy.rs b/src/backup/hierarchy.rs >> index 8dd71fcf7..438bc3ee3 100644 >> --- a/src/backup/hierarchy.rs >> +++ b/src/backup/hierarchy.rs >> @@ -68,19 +68,23 @@ pub fn check_ns_privs_full( >> ); >> } >> >> -pub fn can_access_any_namespace( >> +/// Checks if the given user has read/access rights on any namespace on the given datastore, >> +/// beginning with `start_ns` up to `max_depth` below. >> +pub fn can_access_any_namespace_in_range( > > I would interpret a range being over a linear list, not a tree, the "below" > you use in the doccomment is already much better fitting, like: > > can_access_any_namespace_below > actually what i had at first^^ i opted for range because of the max-depth limiting, but you're right range makes not much sense in a tree > >> store: Arc, >> auth_id: &Authid, >> user_info: &CachedUserInfo, >> + start_ns: Option, > > nit: start is IMO slightly confusing for the tree-like nature of namespaces, maybe > parent_ns would be better suited? sounds good > >> + max_depth: Option, >> ) -> bool { >> + let ns = start_ns.unwrap_or_default(); >> // NOTE: traversing the datastore could be avoided if we had an "ACL tree: is there any priv >> // below /datastore/{store}" helper >> - let mut iter = >> - if let Ok(iter) = store.recursive_iter_backup_ns_ok(BackupNamespace::root(), None) { >> - iter >> - } else { >> - return false; >> - }; >> + let mut iter = if let Ok(iter) = store.recursive_iter_backup_ns_ok(ns, max_depth) { >> + iter >> + } else { >> + return false; >> + }; > > This could use let-else, e.g. something like (untested): > > let Ok(mut iter) = store.recursive_iter_backup_ns_ok(ns, max_depth) else { > return false; > }; > can do, i wanted to stay as close as the original code as possible so it's easier to see that the code only moved should i do that cleanup as an extra commit or should i include it in this one? > >> let wanted = >> PRIV_DATASTORE_AUDIT | PRIV_DATASTORE_MODIFY | PRIV_DATASTORE_READ | PRIV_DATASTORE_BACKUP; >> let name = store.name(); >> @@ -90,6 +94,15 @@ pub fn can_access_any_namespace( >> }) >> } >> >> +/// Checks if the given user has read/access rights on any namespace on given datastore >> +pub fn can_access_any_namespace( >> + store: Arc, >> + auth_id: &Authid, >> + user_info: &CachedUserInfo, >> +) -> bool { >> + can_access_any_namespace_in_range(store, auth_id, user_info, None, None) >> +} >> + >> /// A privilege aware iterator for all backup groups in all Namespaces below an anchor namespace, >> /// most often that will be the `BackupNamespace::root()` one. >> /// > _______________________________________________ pbs-devel mailing list pbs-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pbs-devel