Re: Redact user password on pg_stat_statements
От | Andrew Dunstan |
---|---|
Тема | Re: Redact user password on pg_stat_statements |
Дата | |
Msg-id | 62bdb651-077b-48d5-96f9-67581bee0acd@dunslane.net обсуждение исходный текст |
Ответ на | Re: Redact user password on pg_stat_statements (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Redact user password on pg_stat_statements
Re: Redact user password on pg_stat_statements |
Список | pgsql-hackers |
On 2025-02-21 Fr 11:08 AM, Tom Lane wrote: > Matheus Alcantara <matheusssilv97@gmail.com> writes: >> Attached a patch to redact the password value from pg_stat_statements_view when >> executing: >> { CREATE|ALTER} {USER|ROLE|GROUP } identifier { [WITH] [ENCRYPTED] >> PASSWORD 'value' } > Please see previous threads about hiding this sort of information, > most recently [1]. It's a slippery slope for which there are no > real fixes, and even partial fixes like this one are horrid kluges. > One obvious objection to the direction you propose here is that it > does nothing for pg_stat_activity, nor for the server log if > log_statement is enabled. > > The right answer is to never send cleartext passwords to the server > in the first place. > > regards, tom lane > > [1] https://www.postgresql.org/message-id/flat/18817-771682052a364bfe%40postgresql.org > > I don't think this is such a terrible kluge. I think it's different from the server log case, which after all requires access to the server file system to exploit. I agree that people should not send passwords in cleartext, but I don't know that that means we should never try to ameliorate the risk of doing so. cheers andrew -- Andrew Dunstan EDB: https://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: