From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <d.csapak@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) server-digest SHA256)
(No client certificate requested)
by lists.proxmox.com (Postfix) with ESMTPS id 20CAC906A1
for <pve-devel@lists.proxmox.com>; Wed, 15 Mar 2023 10:55:14 +0100 (CET)
Received: from firstgate.proxmox.com (localhost [127.0.0.1])
by firstgate.proxmox.com (Proxmox) with ESMTP id DD53A79B9
for <pve-devel@lists.proxmox.com>; Wed, 15 Mar 2023 10:54:43 +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 Mar 2023 10:54:40 +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 9623040AC2;
Wed, 15 Mar 2023 10:54:39 +0100 (CET)
Message-ID: <3c2d120e-eb11-aa79-be1f-eba3879cd58a@proxmox.com>
Date: Wed, 15 Mar 2023 10:54:38 +0100
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:110.0) Gecko/20100101
Thunderbird/110.0
To: Proxmox VE development discussion <pve-devel@lists.proxmox.com>,
Christoph Heiss <c.heiss@proxmox.com>
References: <20230131125043.380402-1-c.heiss@proxmox.com>
<20230131125043.380402-2-c.heiss@proxmox.com>
Content-Language: en-US
From: Dominik Csapak <d.csapak@proxmox.com>
In-Reply-To: <20230131125043.380402-2-c.heiss@proxmox.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-SPAM-LEVEL: Spam detection results: 0
AWL 0.061 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
NICE_REPLY_A -0.001 Looks like a legit reply (A)
SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record
SPF_PASS -0.001 SPF: sender matches SPF record
URIBL_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to URIBL was blocked. See
http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block for more
information. [proxmox.com, ldap.pm]
Subject: Re: [pve-devel] [PATCH access-control 1/2] ldap: Allow quoted
values for DN attribute values
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 Mar 2023 09:55:14 -0000
hi,
so high level comment:
i'd write most of what you wrote in the cover letter here in the commit message,
makes it much more convenient to find it only via git ;)
also i'm missing a bit the rationale for how the regex was chosen, besides
that it works in some conditions
further comment inline
On 1/31/23 13:50, Christoph Heiss wrote:
> Signed-off-by: Christoph Heiss <c.heiss@proxmox.com>
> ---
> src/PVE/Auth/LDAP.pm | 8 +++++---
> 1 file changed, 5 insertions(+), 3 deletions(-)
>
> diff --git a/src/PVE/Auth/LDAP.pm b/src/PVE/Auth/LDAP.pm
> index 4792586..4d771e7 100755
> --- a/src/PVE/Auth/LDAP.pm
> +++ b/src/PVE/Auth/LDAP.pm
> @@ -10,6 +10,8 @@ use PVE::Tools;
>
> use base qw(PVE::Auth::Plugin);
>
> +our $dn_regex = qr!\w+=("[\w ,+/<>;=]+"|[^ ,+"/<>;=]+)(,\s*\w+=("[\w ,+/<>;=]+"|[^ ,+"/<>;=]+))*!;
are you sure you did not make it more strict than what is allowed?
e.g. if i had 'foo=<,bar=>' that would have previously worked, but now is forbidden AFAICS
while we can make such changes, we should only do so on major releases where it's a breaking
change, preferably with a workaround and/or script where we can rewrite/warn the user
that it's not valid syntax
OTOH, most users probably won't notice since they did not use such 'strange' values
the problem here is that possibly working configs are not valid anymore
(for logins it's problematic, depending on how the admins log in)
> +
> sub type {
> return 'ldap';
> }
> @@ -19,7 +21,7 @@ sub properties {
> base_dn => {
> description => "LDAP base domain name",
> type => 'string',
> - pattern => '\w+=[^,]+(,\s*\w+=[^,]+)*',
> + pattern => $dn_regex,
> optional => 1,
> maxLength => 256,
> },
> @@ -33,7 +35,7 @@ sub properties {
> bind_dn => {
> description => "LDAP bind domain name",
> type => 'string',
> - pattern => '\w+=[^,]+(,\s*\w+=[^,]+)*',
> + pattern => $dn_regex,
> optional => 1,
> maxLength => 256,
> },
> @@ -91,7 +93,7 @@ sub properties {
> description => "LDAP base domain name for group sync. If not set, the"
> ." base_dn will be used.",
> type => 'string',
> - pattern => '\w+=[^,]+(,\s*\w+=[^,]+)*',
> + pattern => $dn_regex,
> optional => 1,
> maxLength => 256,
> },
> --
> 2.34.1
>
>
>
> _______________________________________________
> pve-devel mailing list
> pve-devel@lists.proxmox.com
> https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
>
>