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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Chapman Flack <chap(at)anastigmatix(dot)net>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: pie-in-sky idea: 'sensitive' function parameters
Date: 2020-05-29 19:26:13
Message-ID: 11308.1590780373@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Chapman Flack <chap(at)anastigmatix(dot)net> writes:
> A possible step in the direction of good-enough would be to have
> 'sensitive' flags only in the parameter-bind message of the extended
> protocol.

Yeah, if we restrict our promises to being willing to not log (some)
bind parameters, that seems far more manageable, and reliable, than
figuring out what parts of query strings need to be hidden.

One missing part of that is that we'd need to support bind parameters
for utility statements, eg new password in ALTER USER. That's been
on the wish list for a long time anyway, of course. I think it's
mostly a matter of lack of round tuits, rather than any fundamental
problem. (Parameters in transaction control statements might have
fundamental problems, but we can just dismiss that as out of scope.)

I don't have a lot of faith (not any, really) in your notion of tying
control of the feature to function arguments. That falls down for
all of the simpler cases I can think of: aside from the ALTER USER
PASSWORD case, there's INSERT INTO accounts(..., creditcardnumber,
...) VALUES(..., $n, ...). Neither one of those have a nearby UDF
to control it with. Also, what would we do with something like
sensitive_function($1 || 'constant') ?

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2020-05-29 19:28:14 Re: pie-in-sky idea: 'sensitive' function parameters
Previous Message Robert Haas 2020-05-29 19:20:09 Re: Internal key management system