Re: BUG #16106: Patch - Radius secrets always gets lowercased

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: mdavid(at)palantir(dot)com
Cc: pgsql-bugs(at)lists(dot)postgresql(dot)org
Subject: Re: BUG #16106: Patch - Radius secrets always gets lowercased
Date: 2019-11-11 20:23:07
Message-ID: 19993.1573503787@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

PG Bug reporting form <noreply(at)postgresql(dot)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/utils/adt/varlena.c#L3652
> I'm attaching a patch for this since I don't think the secrets should ever
> 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

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Thomas Munro 2019-11-11 21:46:43 Re: BUG #16104: Invalid DSA Memory Alloc Request in Parallel Hash
Previous Message PG Bug reporting form 2019-11-11 18:01:35 BUG #16106: Patch - Radius secrets always gets lowercased