From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail02.haj.ipfire.org (localhost [127.0.0.1]) by mail02.haj.ipfire.org (Postfix) with ESMTP id 4ZsxXS4p3Dz3348 for ; Wed, 7 May 2025 13:52:24 +0000 (UTC) Received: from mail01.ipfire.org (mail01.haj.ipfire.org [172.28.1.202]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (secp384r1) server-digest SHA384 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mail01.haj.ipfire.org", Issuer "R10" (verified OK)) by mail02.haj.ipfire.org (Postfix) with ESMTPS id 4ZsxXP19bGz30L0 for ; Wed, 7 May 2025 13:52:21 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mail01.ipfire.org (Postfix) with ESMTPSA id 4ZsxXN08s2zkc; Wed, 7 May 2025 13:52:19 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipfire.org; s=202003rsa; t=1746625940; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=GaZvnzDE1396HopkaJroUzsOnqQxsS82c8U1hEv3wLk=; b=gcXXvn0R4b7rE5zAmjotweXTh6w2fgpAld/Wp2UBrsqSHZpcZ40AuTaGt7PbLXUkzJ2Wj+ jtjDKXtrSWEE2SmnAkcZtx6n9rAl0qRcyD/+dPxt9vx4Q6//sKe8sEE98VdwlKjYXRrnUn h8Ci4aB+VeWCWwsyax/CgiE3CiO7/Hmhy1f+6QKObd8jjqTpUAiOfqUC3jEC9j3uIBaxvk L1538Py96gljM9KU4eTL0z95kh3SpU3U2tNY/4sUTwV6bGua9qW3h3dQJKIFdGMzGsWi9R oGAvj4t0sDHqUJmjRuVEDX5RIbJwWGebImUZo7aLswzj6A0DnjXDNTsIxIUIaQ== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=ipfire.org; s=202003ed25519; t=1746625940; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=GaZvnzDE1396HopkaJroUzsOnqQxsS82c8U1hEv3wLk=; b=qIhG+JcPiDg7lA75a6NXpuTxavmuPA2s+T5drGpX+Fuwdli3Wkabf0EVy1j8tYX5L140Rq 1PdpZguglvxNa5Bg== Message-ID: Date: Wed, 7 May 2025 15:52:16 +0200 Precedence: list List-Id: List-Subscribe: , List-Unsubscribe: , List-Post: List-Help: Sender: Mail-Followup-To: MIME-Version: 1.0 Subject: Re: [PATCH v2] chpasswd.cgi: Fixes bug12755 - v2 with password verification correction To: Michael Tremer References: <20250507124211.16762-1-adolf.belka@ipfire.org> <11929F52-E93F-4C85-9704-51BFDC741FEA@ipfire.org> Content-Language: en-GB Cc: "IPFire: Development-List" From: Adolf Belka In-Reply-To: <11929F52-E93F-4C85-9704-51BFDC741FEA@ipfire.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Hi Michael, On 07/05/2025 14:44, Michael Tremer wrote: > Hello Adolf, > > Thanks for the patch. Is there no return code that we get from htpasswd instead of parsing the output? It gives a return code for everything, with numbers of 0 to 7, except for the use of the -v option to verify the password. This gives password verification failed if the existing password for the specified user is not correct and Password for user fred correct. if the user specified was fred and the specified password was correct. It does the above for both the interactive -v and the batch mode using the command line of -bv I had to use the check for if the string was found in the return variable because if I checked if the string matched the contents of the variable it always failed so I think there is a hidden Carriage Return or something in the output from htpasswd for the verification test. Regards, Adolf. > > -Michael > >> On 7 May 2025, at 13:42, Adolf Belka wrote: >> >> - Realised that I had not tested the old password beinhg correct or not. Previous check >> gave the same answer irrespective of the output coming from the htpasswd verification. >> - This changes the variable used for the system_output result to an array and then >> checks if the first element contains the failure message that htpasswd gives if >> password verification fails. >> - Tested out with correct and incorrect old passwords and gave the correct answer in >> both cases. Confirmed also that the check for the user being present works correctly >> for both an existing and new user name, which it did. >> >> Fixes: bug12755 >> Tested-by: Adolf Belka >> Signed-off-by: Adolf Belka >> --- >> html/cgi-bin/chpasswd.cgi | 4 ++-- >> 1 file changed, 2 insertions(+), 2 deletions(-) >> >> diff --git a/html/cgi-bin/chpasswd.cgi b/html/cgi-bin/chpasswd.cgi >> index c00caca20..46c3e02f6 100644 >> --- a/html/cgi-bin/chpasswd.cgi >> +++ b/html/cgi-bin/chpasswd.cgi >> @@ -77,11 +77,11 @@ if ($cgiparams{'SUBMIT'} eq $tr{'advproxy chgwebpwd change password'}) >> # Check if a user with this name and password exists in the userdb file >> # and if it does then change the password to the new one >> my $user = &General::system_output("grep", "$cgiparams{'USERNAME'}", "$userdb"); >> - my $old_password = &General::system_output("/usr/bin/htpasswd", "-bv", "$userdb", "$cgiparams{'USERNAME'}", "$cgiparams{'OLD_PASSWORD'}"); >> + my @old_password = &General::system_output("/usr/bin/htpasswd", "-bv", "$userdb", "$cgiparams{'USERNAME'}", "$cgiparams{'OLD_PASSWORD'}"); >> if (!$user) { >> $errormessage = $tr{'advproxy errmsg invalid user'}; >> goto ERROR; >> - } elsif (!$old_password) { >> + } elsif (@old_password[0] =~ /password verification failed/) { >> $errormessage = $tr{'advproxy errmsg password incorrect'}; >> goto ERROR; >> } else { >> -- >> 2.49.0 >> >> > >