Re: BUG #15432: ddl logging includes password in plaintext
От | Tom Lane |
---|---|
Тема | Re: BUG #15432: ddl logging includes password in plaintext |
Дата | |
Msg-id | 11303.1539615747@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | BUG #15432: ddl logging includes password in plaintext (PG Bug reporting form <noreply@postgresql.org>) |
Список | pgsql-bugs |
=?utf-8?q?PG_Bug_reporting_form?= <noreply@postgresql.org> writes: > When I have logging set to 'ddl', and create a user, I can see their > password in plain text in the logs: > postgres=# create user example with password 'secretpassword'; > CREATE ROLE > 2018-10-15 10:09:03.513 EDT postgres 127.0.0.1 postgres psql LOG: > statement: create user example with password 'secretpassword'; Yup. There are ways to hash the password on the client side before sending, if you want to defend against that. > This may not technically be a 'bug'. However, it should not be > out-of-the-box behavior. The password itself should be obfuscated from the > logs by default. This complaint has been made before, and rejected before, and I do not foresee the policy changing. Obfuscating the logs is impractical on both performance and system-structural grounds. And if we tried, it would be unreliable --- for instance, if you misspelled any of the keywords in this example command, would you still expect the hypothetical log obfuscator to figure out that it should get rid of 'secretpassword'? Moreover, in most database situations where you'd really care about password secrecy, there is a lot of *other* data going through the system that you'd not want exposed to prying eyes, either. Credit card numbers, personally-identifiable medical data, yadda yadda are all likely to be there in logs of INSERT/UPDATE/SELECT commands. The short answer here is that you need to limit access to the log files just as much as the rest of the database data. regards, tom lane
В списке pgsql-bugs по дате отправления: