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
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 |