Re: BUG #16106: Patch - Radius secrets always gets lowercased
От | Tom Lane |
---|---|
Тема | Re: BUG #16106: Patch - Radius secrets always gets lowercased |
Дата | |
Msg-id | 19993.1573503787@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | BUG #16106: Patch - Radius secrets always gets lowercased (PG Bug reporting form <noreply@postgresql.org>) |
Ответы |
Re: BUG #16106: Patch - Radius secrets always gets lowercased
|
Список | pgsql-bugs |
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/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
В списке pgsql-bugs по дате отправления: