Turner, Ian wrote:
> While trying to connect our PostgreSQL database to our Kerberos realm, we
> encountered the obscure message "Invalid message length". Tracking this down,
> we discovered that it was emitted by src/backend/libpq/pqcomm.c in response
> to a rather large Kerberos message. The root cause is as follows, and a patch
> is below.
>
> The code in src/backend/libpq/auth.c contains a hard-coded limit on the size
> of GSS messages, and in particular on the message containing the client's
> Kerberos ticket for the postgres server. The limit was 2,000 bytes, which is
> normally adequate for tickets based on TGTs issued by Unix KDCs. However,
> TGTs issued by Windows domain controllers contain an authorization field
> known as the PAC (privilege attribute certificate), which contains the user's
> Windows permissions (group memberships etc.). The PAC is copied into all
> tickets obtained on the basis of this TGT (even those issued by Unix realms
> which the Windows realm trusts), and can be several K in size. Thus, GSS
> authentication was failing with a "invalid message length" error. We simply
> upped the limit to 32k, which ought to be sufficient.
>
> The patch is quite brief:
>
> --- postgresql-8.4-8.4.1/src/backend/libpq/auth.c 2009-06-25
> 12:30:08.000000000 +0100
> +++ postgresql-8.4-8.4.1-fixed/src/backend/libpq/auth.c 2009-09-15
> 20:27:01.000000000 +0100
> @@ -166,6 +166,8 @@
> #endif
>
> static int pg_GSS_recvauth(Port *port);
> +
> +#define GSS_MAX_TOKEN_LENGTH (32767)
> #endif /* ENABLE_GSS */
>
>
> @@ -937,7 +939,7 @@
>
> /* Get the actual GSS token */
> initStringInfo(&buf);
> - if (pq_getmessage(&buf, 2000))
> + if (pq_getmessage(&buf, GSS_MAX_TOKEN_LENGTH))
> {
> /* EOF - pq_getmessage already logged error */
> pfree(buf.data);
>
>
> Please let me know if anything additional is required in order to get this
> fix into the next release.
The corresponding limit in pg_SSPI_recvauth() probably needs to be
raised too..
pq_getmessage() doesn't necessarily need a limit, we could accept
arbitrarily long tokens. Although I guess we want to avoid simple
denial-of-service attacks exhausting backend memory.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
