From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from gate001.proxmox.com (gate001.proxmox.com [45.144.208.40]) by lore.proxmox.com (Postfix) with ESMTPS id D4DB91FF0E7 for ; Fri, 10 Jul 2026 08:38:39 +0200 (CEST) Received: from gate001.proxmox.com (localhost.localdomain [127.0.0.1]) by gate001.proxmox.com (Proxmox) with ESMTP id 056DB214AB; Fri, 10 Jul 2026 08:38:39 +0200 (CEST) Message-ID: <44cade0a-6957-4edd-be70-fe508ed4708f@proxmox.com> Date: Fri, 10 Jul 2026 08:38:11 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Beta Subject: Re: [PATCH access-control] fix #7144: auth: ldap: force utf-8 encoding for bind credentials To: Elias Huhsovitz , pve-devel@lists.proxmox.com References: <20260709140007.163539-1-e.huhsovitz@proxmox.com> Content-Language: en-US From: Dominik Csapak In-Reply-To: <20260709140007.163539-1-e.huhsovitz@proxmox.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Bm-Milter-Handled: 55990f41-d878-4baa-be0a-ee34c49e34d2 X-Bm-Transport-Timestamp: 1783665503426 X-SPAM-LEVEL: Spam detection results: 0 AWL 0.071 Adjusted score from AWL reputation of From: address DMARC_MISSING 0.1 Missing DMARC policy KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment (newer systems) SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record SPF_PASS -0.001 SPF: sender matches SPF record Message-ID-Hash: CVE5MIV5Y7SVURP7RDBYVLDRRWH6XVEH X-Message-ID-Hash: CVE5MIV5Y7SVURP7RDBYVLDRRWH6XVEH X-MailFrom: d.csapak@proxmox.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; loop; banned-address; emergency; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header X-Mailman-Version: 3.3.10 Precedence: list List-Id: Proxmox VE development discussion List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: i guess to use the password correctly, we then have to also decode it as utf8 when reading from that file? otherwise the password is different in perl when it comes from the api vs from the file? (otherwise this issue wouldn't have happened?) and we probably also have then to encode it again before passing it to ldap (except if Net::LDAP does this automatically, which i'm not sure of) On 7/9/26 4:00 PM, Elias Huhsovitz wrote: > When saving the LDAP/AD bind password to /etc/pve/priv/realm/.pw, > the file was written using the default byte encoding. This caused > passwords containing non-ASCII characters (e.g., '£' or '§') to be > truncated to their lowest byte, resulting in authentication failures > during subsequent sync operations. > > Pass the 'force_utf8' flag to file_set_contents to ensure the password > is encoded as UTF-8 before being written to disk. > > Signed-off-by: Elias Huhsovitz > --- > src/PVE/Auth/LDAP.pm | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/src/PVE/Auth/LDAP.pm b/src/PVE/Auth/LDAP.pm > index 6a73ee8..21ee047 100755 > --- a/src/PVE/Auth/LDAP.pm > +++ b/src/PVE/Auth/LDAP.pm > @@ -438,7 +438,7 @@ sub ldap_set_credentials { > my $cred_file = ldap_cred_file_name($realmid); > mkdir $ldap_pw_dir; > > - PVE::Tools::file_set_contents($cred_file, $password); > + PVE::Tools::file_set_contents($cred_file, $password, 0600, 1); > > return $cred_file; > }