El día martes, febrero 18, 2025 a las 10:37:52 -0500, Tom Lane escribió:
> Indrajeeth Deshmukh <bkindrajeeth@gmail.com> writes:
> > Thanks for sharing the details. It looks like a valid issue and has not
> > been resolved yet. Currently, the solution is keeping the file remains
> > secure, but when it comes to SIEM monitoring, it will be a major concern.
> > Any thoughts on this?
>
> The real bottom-line answer to that is that passwords are just the
> tip of the iceberg. The server log is likely to contain other
> critical information depending on your application; consider credit
> card numbers, HIPAA-protected medical details, etc. The server
> has no way at all to know which fields might be sensitive in that
> way. Even if we had some notion of which fields to hide, in cases
> like statements with syntax errors, we couldn't reliably identify
> which parts of a query string are sensitive.
>
> The only solution is to treat the server log files with the same
> amount of care as you give to the database files themselves.
> Or send them to /dev/null, but that's unlikely to be very workable
> in practice.
>
> Independently of that, best practice is to never send cleartext
> passwords to the server in the first place. psql has support
> for setting a password without that, and I think libpq does too.
What do I have to configure in the PostgreSQL server to get this
reproduced? I tried:
$ psql -Usisis testdb
psql (15.1, server 16.5)
WARNING: psql major version 15, server major version 16.
Some psql features might not work.
Type "help" for help.
testdb=# CREATE USER bla WITH PASSWORD 'bla';
CREATE ROLE
testdb=#
and have nothing in the log:
$ tail /data/postgresql165/log/postgresql-2025-02-19_000000.log
...
2025-02-19 06:15:23.582 CET [1947] LOG: checkpoint complete: wrote 1421 buffers (8.7%); 0 WAL file(s) added, 1
removed,0 recycled; write=142.168 s, sync=0.003 s, total=142.186 s; sync files=57, longest=0.002 s, average=0.001 s;
distance=18403kB, estimate=18403 kB; lsn=5/72470898, redo lsn=5/7246F048
I even set
log_statement = 'all'
and restarted the server - nothing.
The purpose of my question is to inform our 50++ PostgreSQL customers
what they must avoid...
Thanks
matthias
--
Matthias Apitz, ✉ guru@unixarea.de, http://www.unixarea.de/ +49-176-38902045
Public GnuPG key: http://www.unixarea.de/key.pub
