From: Tom Lane <tgl@sss.pgh.pa.us>
To: mdavid@palantir.com
cc: pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #16106: Patch - Radius secrets always gets lowercased
In-reply-to: <16106-7d319e4295d08e70@postgresql.org>
References: <16106-7d319e4295d08e70@postgresql.org>
Comments: In-reply-to PG Bug reporting form <noreply@postgresql.org>
	message dated "Mon, 11 Nov 2019 18:01:35 +0000"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <19992.1573503787.1@sss.pgh.pa.us>
Content-Transfer-Encoding: quoted-printable
Date: Mon, 11 Nov 2019 15:23:07 -0500
Message-ID: <19993.1573503787@sss.pgh.pa.us>
Precedence: bulk

PG Bug reporting form <noreply@postgresql.org> writes:
> I'm using radius authentication in pg_hba.conf and I've run into the
> following issue.
> The radiussecrets is always getting lowercased even if I start it with
> double quotes. Seems the double quotes are removed by the tokenization
> process and then the secret gets lowercased by =

> https://github.com/postgres/postgres/blob/REL_12_STABLE/src/backend/util=
s/adt/varlena.c#L3652
> I'm attaching a  patch for this since I don't think the secrets should e=
ver
> be lowercased.

Hm.  I know zip about RADIUS but this seems like generally a sane
change to make.  The other very-dubious-in-this-context assumption
that is embedded in SplitIdentifierString is that the strings should
be truncated at NAMEDATALEN.

Why did you not change the parsing for all four RADIUS options?
Probably case-folding wouldn't matter for the server names,
but the length limitation could.

(Hmm ... on the same principle, PostmasterMain probably shouldn't
be using this function for parsing ListenAddresses.)

I'm hesitant to back-patch a change like this, because in theory
it could change a working configuration into a non-working one.
But it'd be sensible to do in HEAD.

			regards, tom lane