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 694DC1FF15C for ; Fri, 3 Oct 2025 11:52:58 +0200 (CEST) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id E4A581FCD2; Fri, 3 Oct 2025 11:52:57 +0200 (CEST) Message-ID: <28f638cf-5e76-4b68-8594-6860a8ea22b5@proxmox.com> Date: Fri, 3 Oct 2025 11:52:54 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Beta To: Proxmox Backup Server development discussion , Dominik Csapak References: <20251003085045.1346864-1-d.csapak@proxmox.com> <20251003085045.1346864-3-d.csapak@proxmox.com> Content-Language: en-US From: Thomas Lamprecht In-Reply-To: <20251003085045.1346864-3-d.csapak@proxmox.com> X-Bm-Milter-Handled: 55990f41-d878-4baa-be0a-ee34c49e34d2 X-Bm-Transport-Timestamp: 1759485150061 X-SPAM-LEVEL: Spam detection results: 0 AWL -0.176 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-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: pbs-devel-bounces@lists.proxmox.com Sender: "pbs-devel" 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 > 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? > + 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; }; > 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