Re: SET SESSION AUTHORIZATION superuser limitation. - Mailing list pgsql-hackers
| From | Craig Ringer |
|---|---|
| Subject | Re: SET SESSION AUTHORIZATION superuser limitation. |
| Date | |
| Msg-id | CAMsr+YH+zi3=tQXkX2Mn1hWVD0_E+enxt3127nrnwBuQmbmiew@mail.gmail.com Whole thread Raw |
| In response to | Re: SET SESSION AUTHORIZATION superuser limitation. (Tom Lane <tgl@sss.pgh.pa.us>) |
| Responses |
Re: SET SESSION AUTHORIZATION superuser limitation.
|
| List | pgsql-hackers |
On 21 December 2015 at 22:57, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Robert Haas <robertmhaas@gmail.com> writes:
> On Sun, Dec 20, 2015 at 1:47 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> The syntax you propose exposes the user's password in cleartext in
>> the command, where it is likely to get captured in logs for example.
>> That's not going to do.
> Of course, right now, the ALTER USER ... PASSWORD command has that
> problem which is, uh, bad.
Which is why we invented the ENCRYPTED PASSWORD syntax
... which doesn't actually help anything much at all.
It prevents exposure of the user's cleartext password, sure, but the hashed ("encrypted") password passed to ALTER USER ... ENCRYPTED PASSWORD is sufficient to log in. It substitutes for the original password entirely.
Right now the logs just have to be treated as security critical. Which sucks, but is not easily solved.
Nothing is going to stop:
ALTER USER fred PASSSSWORD 'sekrit';
from logging the password in a syntax error. But it'd be nice to let utility commands define a log hook that lets them emit a sanitized version of themselves based on their parse tree representation to the logs.
Except that users will want to be able to mask log output too. I see lots of questions about how to stop pgcrypto sql function calls from exposing key materials in the logs. Right now the answer is "you can't". With logging based on the raw statement text before parsing I don't see any way to change that. I advise people to do their symmetric crypto and their secret key operations in the application instead, which has the advantage of also better isolating the key material from its persistent storage in the database.
We have to be able to emit syntax errors and other things that use the raw SQL text. We also don't have any functionality to turn a parsetree back into SQL text with parts of it masked out, and it'd be impractical to do that just for logging anyway.
I can see it being useful to be able to set a session level flag that limits logging to command tags, not command text. Let the superuser GRANT the right to set it to other users. Use a GUC to toggle it, preferably via SET LOCAL. It has to be session level not statement level because we've got no way to set generic options per-statement, and plus that'd risk leaking the statement on a parse error. We'd probably replace the statement text with a string like 'PARSE_ERROR' until the command tag was known, then replace it with the command tag. This would reduce the audit utility of the logs a little, but if it's superuser-only unless granted you're already stuffed if someone who's not meant to gets hold of it.
--
pgsql-hackers by date: