On Fri, May 29, 2020 at 12:38 PM Chapman Flack <c...@anastigmatix.net> wrote: > Just giving this thread a bump in honor of the mention of sensitive > things in logs in the cryptography unconference session.
I agree that there's a problem here and I would like to see a solution to it, too. Several EnterpriseDB customers have complained about the fact that ALTER USER .. PASSWORD logs the password, which is a similar kind of problem, though it involves DDL rather than DML. But, I don't really see a way forward that doesn't involve breaking stuff that works today. We have options to log queries before parsing them. You can't redact sensitive details at that point because you don't know whether the query contains any such details, or where they are located. You can't postpone logging the query without changing the behavior of the system in user-visible ways. What if parsing gets stuck in an infinite loop and you want to look at the log to see which query got stuck? What if you want to look at the timestamps on the log messages to know when the server started dealing with some particular query? On a related note, what if parsing fails? Not only should the logging that happens before parsing already have been done, but the parse error itself should also log the query that triggered it, so that the user has some chance of troubleshooting the situation. However, since we haven't completed parsing, there's no way to redact what gets logged in such a case; we can't know where the sensitive stuff is. Now, you might say that you only care about redacting queries that are well-formed, but parsing can fail for other reasons - e.g. because you ran out of memory. You could argue that such cases are unlikely enough that you don't care about them, but that doesn't mean somebody else won't file a CVE. Also, even if you are logging after parsing has been successfully completed, does that mean that you know which parts of the query contain sensitive information? Parse trees contain some positional information, but I'm not sure that there's enough information there, or that we have it in all the cases somebody might want to redact. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
