From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <f.ebner@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 EA35A984B0
 for <pve-devel@lists.proxmox.com>; Wed, 15 Nov 2023 09:31:42 +0100 (CET)
Received: from firstgate.proxmox.com (localhost [127.0.0.1])
 by firstgate.proxmox.com (Proxmox) with ESMTP id C2F5D1B07
 for <pve-devel@lists.proxmox.com>; Wed, 15 Nov 2023 09:31:12 +0100 (CET)
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) server-digest SHA256)
 (No client certificate requested)
 by firstgate.proxmox.com (Proxmox) with ESMTPS
 for <pve-devel@lists.proxmox.com>; Wed, 15 Nov 2023 09:31:12 +0100 (CET)
Received: from proxmox-new.maurer-it.com (localhost.localdomain [127.0.0.1])
 by proxmox-new.maurer-it.com (Proxmox) with ESMTP id CF5F142EE4
 for <pve-devel@lists.proxmox.com>; Wed, 15 Nov 2023 09:31:11 +0100 (CET)
Message-ID: <a3e7c9cc-50f8-448f-b5d4-e6178933f03d@proxmox.com>
Date: Wed, 15 Nov 2023 09:31:06 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
To: Proxmox VE development discussion <pve-devel@lists.proxmox.com>,
 Philipp Hufnagl <p.hufnagl@proxmox.com>
References: <20231114142714.27578-1-p.hufnagl@proxmox.com>
Content-Language: en-US
From: Fiona Ebner <f.ebner@proxmox.com>
In-Reply-To: <20231114142714.27578-1-p.hufnagl@proxmox.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-SPAM-LEVEL: Spam detection results:  0
 AWL -0.079 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
 T_SCC_BODY_TEXT_LINE    -0.01 -
 URIBL_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to URIBL was blocked. See
 http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block for more
 information. [pbsplugin.pm]
Subject: Re: [pve-devel] [PATCH storage] fix #5008: prevent adding pbs
 storage with invalid namespace
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: Wed, 15 Nov 2023 08:31:43 -0000

Am 14.11.23 um 15:27 schrieb Philipp Hufnagl:
> Currently, when adding a PBS storage with a namespace that does not
> exist, the storage gets added normally, but browsing/using it only
> returns a cryptic error message.
> 
> This change checks if the namespace entered when adding is valid and
> prompts an error if it is not. If no namespace is provided, the storage
> will be added without error.

Does not fully describe the change: It checks if the namespace is valid
each time the storage is activated, not just when adding.

> 
> Signed-off-by: Philipp Hufnagl <p.hufnagl@proxmox.com>
> ---
>  src/PVE/Storage/PBSPlugin.pm | 21 ++++++++++++++++++++-
>  1 file changed, 20 insertions(+), 1 deletion(-)
> 
> diff --git a/src/PVE/Storage/PBSPlugin.pm b/src/PVE/Storage/PBSPlugin.pm
> index 4320974..aceb2c4 100644
> --- a/src/PVE/Storage/PBSPlugin.pm
> +++ b/src/PVE/Storage/PBSPlugin.pm
> @@ -817,6 +817,17 @@ sub scan_datastores {
>      return $response;
>  }
>  
> +sub scan_namespaces {
> +    my ($scfg, $datastore, $password) = @_;
> +
> +    my $conn = pbs_api_connect($scfg, $password);

Not super important, but would be nice to have a way to re-use the same
connection in scan_datastores() and here, since activate_storage() will
call both of them.

> +
> +    my $namespaces = eval { $conn->get("/api2/json/admin/datastore/$datastore/namespace", {}); };
> +    die "error fetching namespaces - $@" if $@;
> +
> +    return $namespaces;
> +}
> +
>  sub activate_storage {
>      my ($class, $storeid, $scfg, $cache) = @_;
>  
> @@ -826,10 +837,18 @@ sub activate_storage {
>      die "$storeid: $@" if $@;
>  
>      my $datastore = $scfg->{datastore};
> +    my $namespace = $scfg->{namespace};
>  
>      for my $ds (@$datastores) {
>  	if ($ds->{store} eq $datastore) {
> -	    return 1;
> +	    return 1 if !defined($namespace);
> +	    my $namespaces = eval { scan_namespaces($scfg, $datastore, $password) };

Why use eval and ignore the error here? Like that users (and we) won't
know if the api request or connection failed and just get the error
message from below about permissions/existence then.

> +	    for my $ns (@$namespaces) {
> +		if ($ns->{ns} eq $namespace) {
> +		    return 1;
> +		}
> +	    }
> +	    die "$storeid: Cannot find namespace '$namespace', check permissions and existence!\n";
>  	}
>      }
>