Hi everyone, This started as a conversation on Discord. Someone asked if Postgres logs which line in pg_hba.conf matched against a certain login attempt, and I said no. That's not quite right, as enabling log_connections includes a line like this:
2023-08-15 13:26:03.159 PDT [692166] postgres@snip LOG: connection authenticated: identity="postgres" method=md5 (/etc/postgresql/15/main/pg_hba.conf:107) But I wasn't getting that output. I finally gave up and looked at the code, where I found that this particular output is only generated by the set_authn_id function. So if that function is never called, there's no message saying which line from the pg_hba.conf file matched a particular login. The switch statement that decodes port->hba->auth_method ends by simply setting status = STATUS_OK; with no supplementary output since it never calls set_authn_id. So in theory, a malicious user could add a trust line to pg_hba.conf and have unlimited unlogged access to the database. Unless you happen to notice that the "connection authenticated" line has disappeared, it would look like normal activity. Would it make sense to decouple the hba info from set_authn_id so that it is always logged even when new auth methods get added in the future? Or alternatively create a function call specifically for that output so it can be produced from the trust case statement and anywhere else that needs to tag the auth line. I personally would love to see if someone got in through a trust line, ESPECIALLY if it isn't supposed to be there. Like: 2023-08-15 13:26:03.159 PDT [692166] postgres@snip LOG: connection authenticated: identity="postgres" method=trust (/etc/postgresql/15/main/pg_hba.conf:1) Perhaps I'm being too paranoid; It just seemed to be an odd omission. Euler Taveira clued me into the initial patch which introduced the pg_hba.conf tattling: https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=9afffcb833d3c5e59a328a2af674fac7e7334fc1 I read through the discussion, and it doesn't seem like the security aspect of simply hiding trust auths from the log was considered. Since this is a new capability, I suppose nothing is really different from say Postgres 14 and below. Still, it never hurts to ask. Cheers! -- Shaun Thomas High Availability Architect EDB www.enterprisedb.com