Re: Proposal: Save user's original authenticated identity for logging

Поиск
Список
Период
Сортировка
От Michael Paquier
Тема Re: Proposal: Save user's original authenticated identity for logging
Дата
Msg-id YGqkZeicvgHbMVvO@paquier.xyz
обсуждение исходный текст
Ответ на Re: Proposal: Save user's original authenticated identity for logging  (Michael Paquier <michael@paquier.xyz>)
Ответы Re: Proposal: Save user's original authenticated identity for logging
Список pgsql-hackers
On Sat, Apr 03, 2021 at 09:30:25PM +0900, Michael Paquier wrote:
> Slight rebase for this one to take care of the updates with the SSL
> error messages.

I have been looking again at that and applied it as c50624cd after
some slight modifications.  Attached is the main, refactored, patch
that plugs on top of the existing infrastructure.  connect_ok() and
connect_fails() gain two parameters each to match or to not match the
logs of the backend, with a truncation of the logs done before any
connection attempt.

I have spent more time reviewing the backend code while on it and
there was one thing that stood out:
+       ereport(FATAL,
+               (errmsg("connection was re-authenticated"),
+                errdetail_log("previous ID: \"%s\"; new ID: \"%s\"",
+                              port->authn_id, id)));
This message would not actually trigger because auth_failed() is the
code path in charge of showing an error here, so this could just be
replaced by an assertion on authn_id being NULL?  The contents of this
log were a bit in contradiction with the comments a couple of lines
above anyway.  Jacob, what do you think?
--
Michael

Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Amul Sul
Дата:
Сообщение: Re: [Patch] ALTER SYSTEM READ ONLY
Следующее
От: Bharath Rupireddy
Дата:
Сообщение: Re: TRUNCATE on foreign table