BUG #15432: ddl logging includes password in plaintext

From: PG Bug reporting form <noreply(at)postgresql(dot)org>
To: pgsql-bugs(at)lists(dot)postgresql(dot)org
Cc: rotten(at)windfish(dot)net
Subject: BUG #15432: ddl logging includes password in plaintext
Date: 2018-10-15 14:44:24
Message-ID: 15432-be79e9461630b14c@postgresql.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

The following bug has been logged on the website:

Bug reference: 15432
Logged by: Rick Otten
Email address: rotten(at)windfish(dot)net
PostgreSQL version: 11rc1
Operating system: Ubuntu 18.04
Description:

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';

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. Perhaps there are some use cases where seeing the actual
password in the logs is useful, but they should be an edge case and not
typical.

I'd like to forward all logs to a centralized logging system. I do not want
to forward passwords in plain text to it. I could make a "postgresql-aware
log forwarder" that obfuscates the passwords before forwarding the logs,
however I'm also not comfortable with all of the passwords sitting around on
disk and disk backups in the logs in plain text either.

On the other hand, I definitely want to log all DDL and other changes that
are happening to the system, so I don't want to set log level lower.

I saw in a greenplum blog [
https://community.pivotal.io/s/article/How-to-Create-a-User-with-an-Encrypted-Password
] at I might be able "pre-hash" the password in some scenarios and then use
that when I create the user or role so the hash ends up in the logs instead
of the plain text. That seems hacky, at best. The examples on that page
use md5, I'm not sure it would work with scram-sha-256. Based on the
documentation I think it will work with PG 11. I'll experiment with that
potential work-around, meanwhile I wanted to log this issue (since I didn't
find it with the searches I ran) - many DBA's may not even notice those
lines going by in their log files and realize this is exposure they might
not want.

It would be much easier on us resource strapped pg admins if the logs simply
didn't log the password itself.

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message PG Bug reporting form 2018-10-15 14:53:04 BUG #15433: pgagent install question
Previous Message PG Bug reporting form 2018-10-15 09:05:56 BUG #15431: failed to add ltree item to gist index