redacting password in SQL statement in server log
Hackorum builds and tests every patch posted to the lists, not only commitfest submissions. This is Hackorum's own CI rather than the PostgreSQL project's, and it is still under testing - please report anything that looks wrong.
You can run a PostgreSQL built from this patch straight from Docker, with no checkout and no build:
docker run --rm -p 5432:5432 ghcr.io/hackorum-dev/postgres-patch:t46282psql -h localhost -U postgresBuilt from patchset v1 (message #1), September 20, 2026 at 11:22 AM.
Every patchset is also pushed to a branch of our PostgreSQL fork, so you can check out the same tree CI built. Without a PostgreSQL checkout:
git clone --branch t46282_1 https://github.com/hackorum-dev/postgres.gitIn a checkout you already have, add the fork once:
git remote add hackorum https://github.com/hackorum-dev/postgres.gitthen, for this patchset and every later one:
git fetch hackorum t46282_1 && git checkout t46282_1Patchset v1 (message #1) is on t46282_1
Hi,
Currently, in situation such as duplicate role creation, the server log
would show something such as the following:
2022-07-22 13:48:18.251 UTC [330] STATEMENT: CREATE ROLE test WITH LOGIN
PASSWORD 'foobar';
The password itself should be redacted before logging the statement.
Here is sample output with the patch applied:
2022-07-23 23:28:20.359 UTC [16850] ERROR: role "test" already exists
2022-07-23 23:28:20.359 UTC [16850] STATEMENT: CREATE ROLE test WITH LOGIN
PASSWORD
Please take a look at the short patch.
I know variables should be declared at the start of the func - I can do
that once the approach is confirmed.
Cheers
Zhihong Yu <zyu@yugabyte.com> writes:
Currently, in situation such as duplicate role creation, the server log
would show something such as the following:
2022-07-22 13:48:18.251 UTC [330] STATEMENT: CREATE ROLE test WITH LOGIN
PASSWORD 'foobar';
The password itself should be redacted before logging the statement.
This has been proposed multiple times, and rejected multiple times,
primarily because it offers only false security: you'll never cover
all the cases. (The proposed patch manages to create a bunch of
false positives to go along with its false negatives, too.)
The only safe answer is to be sure to keep the server log contents
secure. Please see prior discussions in the archives.
regards, tom lane
On Sat, Jul 23, 2022 at 5:27 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
Zhihong Yu <zyu@yugabyte.com> writes:
Currently, in situation such as duplicate role creation, the server log
would show something such as the following:2022-07-22 13:48:18.251 UTC [330] STATEMENT: CREATE ROLE test WITH LOGIN
PASSWORD 'foobar';The password itself should be redacted before logging the statement.
This has been proposed multiple times, and rejected multiple times,
primarily because it offers only false security: you'll never cover
all the cases. (The proposed patch manages to create a bunch of
false positives to go along with its false negatives, too.)The only safe answer is to be sure to keep the server log contents
secure. Please see prior discussions in the archives.regards, tom lane
Pardon my laziness.
I will pay more attention.
On Sat, Jul 23, 2022 at 5:27 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
Zhihong Yu <zyu@yugabyte.com> writes:
Currently, in situation such as duplicate role creation, the server log
would show something such as the following:2022-07-22 13:48:18.251 UTC [330] STATEMENT: CREATE ROLE test WITH LOGIN
PASSWORD 'foobar';The password itself should be redacted before logging the statement.
This has been proposed multiple times, and rejected multiple times,
primarily because it offers only false security: you'll never cover
all the cases. (The proposed patch manages to create a bunch of
false positives to go along with its false negatives, too.)The only safe answer is to be sure to keep the server log contents
secure. Please see prior discussions in the archives.regards, tom lane
Hi,
I am thinking of adding `if not exists` to `CREATE ROLE` statement:
CREATE ROLE trustworthy if not exists;
In my previous example, if the user can issue the above command, there
would be no SQL statement logged.
Do you think it is worth adding `if not exists` clause ?
Thanks
Hi,
On Sun, Jul 24, 2022 at 04:33:59AM -0700, Zhihong Yu wrote:
I am thinking of adding `if not exists` to `CREATE ROLE` statement:
CREATE ROLE trustworthy if not exists;
In my previous example, if the user can issue the above command, there
would be no SQL statement logged.
It's not because there might not be an error that the password wouldn't end up
in the logs (log_statement, log_min_duration_statement, typo in the
command...).
Do you think it is worth adding `if not exists` clause ?
This has already been discussed and isn't wanted. You can refer to the last
discussion about that at:
/messages/by-id/CAOxo6XJy5_fUT4uDo2251Z_9whzu0JJGbtDgZKqZtOT9KhOKiQ@mail.gmail.com