Re: Redact user password on pg_stat_statements
| От | Greg Sabino Mullane |
|---|---|
| Тема | Re: Redact user password on pg_stat_statements |
| Дата | |
| Msg-id | CAKAnmmLyAMqSi0PUgOR4UsaF4xEkKWaqzS=GMOdbe6sDQecf4Q@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: Redact user password on pg_stat_statements (Sami Imseih <samimseih@gmail.com>) |
| Ответы |
Re: Redact user password on pg_stat_statements
|
| Список | pgsql-hackers |
On Tue, Feb 25, 2025 at 10:12 AM Sami Imseih <samimseih@gmail.com> wrote:
> What about a more general solution, such as a flag to turn off logging of ALTER ROLE statements completely?
IMO, flags for a specific type of utility statement seems way too much for pg_stat_statements, and this will also not completely prevent leaking plain text passwords from all ways that CREATE/ALTER ROLE could be run, i.e. DO blocks, inside functions/procs with track=all.
Well sure, but best effort is better than no effort at all. Preventing CREATE/ALTER will catch 99% of items, and as I advocated, there really is no reason for them to be in pg_stat_statements in the first place.
The clients that set passwords could simply turn off track_utility on a user/transaction level while they are performing the action with
sensitive data.
Good point, but that relies on the client to do the right thing, and requires two extra steps.
Cheers,
Greg
--
Crunchy Data - https://www.crunchydata.com
Enterprise Postgres Software Products & Tech Support
В списке pgsql-hackers по дате отправления: