Re: pie-in-sky idea: 'sensitive' function parameters

On 02/02/18 22:46, Tom Lane wrote:

> ... the problem with this idea is that knowledge that the item ought to be
> hidden would be obtained only very late in the parsing process. So for
> example if you fat-fingered something just to the left of the function
> call in the query text, or the name of the function itself, your password
> would still get exposed in the log.

That didn't seem like a deal-breaker to me, as the common case I had
imagined for it would be where the query is coded into something (a webapp,
say) that just has some bits of sensitive data to pass in, and would surely
just be tested on dummy data until it was clear the canned query was at
least free of fat-finger issues.

Indeed, should the feature have to be restricted for practicality's sake
to only working with bound parameters and certain protocol variants, it
might not be easy or even possible to use it improvisationally from psql,
but that might be an acceptable limitation.

On 02/03/18 02:14, Craig Ringer wrote:

> About the only time I think it's really viable to pursue is if it's
> restricted to bind parameters. We only log those later and more
> selectively as it is, so it seems much more reasonable to say "I never
> want <parameter X> to appear in the logs".

And I think that could be an acceptable restriction. One way could use
a simple flag to accompany the parameter binding from the client, which
would be recognized early enough to keep the parameter out of the logs,
but also checked later when the function info is available, throwing an
error if it was used for a parameter not declared sensitive, or not used
for a parameter that is.

Or it could even have to be used in a prepared statement. A little
clunkier and one more round trip to the server, but probably not onerous,
and by the time PREPARE completes, surely it can be known which parameter
slots are declared that way.

Still wouldn't account for internal statements logged or errors thrown
by whatever the function does, but maybe the existing machinery for
declaring functions leakproof is at least a start on that?

-Chap