From: Tom Lane <tgl@sss.pgh.pa.us>
To: liulang <lang.liu@esgyn.cn>
Cc: pgsql-bugs@lists.postgresql.org
Subject: Re: lost status 'STATUS_EOF' for authentication when using 'MD5' or 'scram-sha-256'
Date: Tue, 02 Jan 2024 15:28:40 -0500
Message-ID: <12829.1704227320@sss.pgh.pa.us> (raw)
In-Reply-To: <b725238c-539d-cb09-2bff-b5e6cb2c069c@esgyn.cn>
References: <b725238c-539d-cb09-2bff-b5e6cb2c069c@esgyn.cn>
liulang <lang.liu@esgyn.cn> writes:
> The above code does not affect the database execution,but
> ClientAuthentication_hook will be confused whether the password is
> incorrect or not currently entered?
> so.. The CheckPWChallengeAuth should returns STATUS_EOF when It is, I think.
Yeah, I think you are right. Overriding the subroutine's result
here is mistaken, even without considering whether it confuses any
ClientAuthentication_hook. The whole point, as per the comments,
is to not betray to the remote end whether or not there is a user
with a password set. But if we substitute STATUS_ERROR for
STATUS_EOF then we cause exactly that to happen: if the remote closes
the connection for send only, it can tell by whether an error comes
back whether or not the code found a password.
I think we can do it more simply than you suggest though. Just
drop the "return STATUS_ERROR" bit; the Assert is enough.
regards, tom lane
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-bugs@postgresql.org
Cc: tgl@sss.pgh.pa.us, lang.liu@esgyn.cn, pgsql-bugs@lists.postgresql.org
Subject: Re: lost status 'STATUS_EOF' for authentication when using 'MD5' or 'scram-sha-256'
In-Reply-To: <12829.1704227320@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox