Sami Imseih <samims...@gmail.com> writes:
>> What about a more general solution, such as a flag to turn off logging of
>> ALTER ROLE statements completely?
> IMO, flags for a specific type of utility statement seems way too much
> for pg_stat_statements, and this will also not completely prevent leaking
> plain text passwords from all ways that CREATE/ALTER ROLE could be
> run, i.e. DO blocks, inside functions/procs with track=all.
There is a fundamental conflict between the (understandable) desire
for a feature like this and the equally-understandable desire for
database command tracing and logging. For better or worse, we've
pretty much cast our lot with the more-and-more-tracing-and-logging
side of that. I don't want to get into a position where every
available introspection feature has to be aware of an obfuscation
rule and it's a security bug if it's not.
So I think the right path forward is to make it easier for
applications to do things in a more secure way. (Maybe it's still
a security bug if they fail to, but it's their bug not ours.)
We already have things like \password in psql. The most obvious
helper feature we could add for this on the server side is to allow
the password to be an out-of-line parameter:
alter role joe set password $1;
That doesn't eliminate leakage to the server log, since we do log
parameter values. But it'd solve the problem for most other
tracing features. (And maybe we could suppress logging of
parameter values for certain command types? Not sure how much
parsing happens before we log.)
I expressed misgivings about allowing parameters in utility
commands in another nearby thread, and I'm still not sure if
it's a totally great idea. But perhaps it's worth looking into.
regards, tom lane
