Increase limit on max length of the password( pg versions < 14)
Hi hackers,
We have encountered an issue (invalid message length) when the
password length is > 1000 in pg 11,12,13 versions. This is due to the
limit(1000) on the max length of the password. In this case the
password is an access token(JWT) which can have varied lengths >
1000. I see that this is already handled for GSS and SSPI
authentication tokens where the maximum accepted size is 65535.
This is not the case with pg versions >=14 as the limit on max length
is 65535(this change was added as part of sanity checks[1]/messages/by-id/2003757.1619373089@sss.pgh.pa.us).
So we have two options:
1. Backport patch[1]/messages/by-id/2003757.1619373089@sss.pgh.pa.us to 11,12,13
2. Change ONLY the limit on the max length of the password(my patch attached).
Please let me know your thoughts.
Thanks,
Mahendrakar.
Attachments:
v1-0001-Increase-limit-for-max-length-of-the-password.patchapplication/octet-stream; name=v1-0001-Increase-limit-for-max-length-of-the-password.patchDownload
From e6378ffdae96fe41c22a6bab1352ccec99ba78e3 Mon Sep 17 00:00:00 2001
From: Mahendrakar Srinivasarao <mahendrakars@microsoft.com>
Date: Thu, 13 Jul 2023 13:19:44 +0530
Subject: [PATCH v1] Increase limit for max length of the password
---
src/backend/libpq/auth.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/backend/libpq/auth.c b/src/backend/libpq/auth.c
index a533786f08..ea6f27930b 100644
--- a/src/backend/libpq/auth.c
+++ b/src/backend/libpq/auth.c
@@ -685,7 +685,7 @@ recv_password_packet(Port *port)
}
initStringInfo(&buf);
- if (pq_getmessage(&buf, 1000)) /* receive password */
+ if (pq_getmessage(&buf, PG_MAX_AUTH_TOKEN_LENGTH)) /* receive password */
{
/* EOF - pq_getmessage already logged a suitable message */
pfree(buf.data);
--
2.25.1
On 18 Jul 2023, at 11:30, mahendrakar s <mahendrakarforpg@gmail.com> wrote:
So we have two options:
1. Backport patch[1] to 11,12,13
2. Change ONLY the limit on the max length of the password(my patch attached).
We typically only backpatch bugfixes and not functional changes, and this seems
to fall in the latter category.
As the size of the JWT depends on the number of claims in it, are you able to
reduce the number of claims to stay under the limit as a workaround?
--
Daniel Gustafsson
Access token length with bare minimal claims is more than 1000 in this case.
Workarounds are not possible in production.
Show quoted text
On Tue, 18 Jul 2023 at 15:10, Daniel Gustafsson <daniel@yesql.se> wrote:
On 18 Jul 2023, at 11:30, mahendrakar s <mahendrakarforpg@gmail.com> wrote:
So we have two options:
1. Backport patch[1] to 11,12,13
2. Change ONLY the limit on the max length of the password(my patch attached).We typically only backpatch bugfixes and not functional changes, and this seems
to fall in the latter category.As the size of the JWT depends on the number of claims in it, are you able to
reduce the number of claims to stay under the limit as a workaround?--
Daniel Gustafsson
On 7/18/23 11:30, mahendrakar s wrote:
Hi hackers,
We have encountered an issue (invalid message length) when the
password length is > 1000 in pg 11,12,13 versions. This is due to the
limit(1000) on the max length of the password. In this case the
password is an access token(JWT) which can have varied lengths >
1000. I see that this is already handled for GSS and SSPI
authentication tokens where the maximum accepted size is 65535.This is not the case with pg versions >=14 as the limit on max length
is 65535(this change was added as part of sanity checks[1]).So we have two options:
1. Backport patch[1] to 11,12,13
2. Change ONLY the limit on the max length of the password(my patch attached).Please let me know your thoughts.
The third option is to upgrade.
--
Vik Fearing
Vik Fearing <vik@postgresfriends.org> writes:
On 7/18/23 11:30, mahendrakar s wrote:
We have encountered an issue (invalid message length) when the
password length is > 1000 in pg 11,12,13 versions.
The third option is to upgrade.
Yeah. I don't see any good reason to consider this behavior change as
something other than a new feature. Also, the proposed patch is
effectively cherry-picking one single line of the combined effect of
two rather large patches (67a472d71 and 9626325da). I'm unconvinced
that it does very much of use without the rest of those patches; but
we are most certainly not back-patching 67a472d71.
regards, tom lane