On 05/17/21 16:35, Magnus Hagander wrote:
> So you're saying that some entries int he parameter section would
> depend on the db/user/ip combo and some would depend just on the ip?
I don't *think* that's what I was saying. What I was thinking was this:
The pg_hba.conf file is an ordered list of entries. Each entry can specify
a (broad or narrow) set of IPs it applies to, a (broad or narrow) set of
databases it applies to, and a (broad or narrow) set of users it applies to.
Also, in this hypothetical, it can specify a min protocol version.
Right now, we're doing something like this:
1. accept an incoming connection, learning the client IP
2. SSLRequest message leads to negotiating TLS
3. StartupMessage supplies the desired database and user name
4. pg_hba entries are consulted once and filtered down to the first one
applicable to the client IP, database, and username (and SSLness)
5. that entry is used for authentication
I suggested only:
Insert step 1½, filter the pg_hba entries down to only those that could
possibly accept a connection from this IP address. This is an improper
subset of the whole list, and an improper superset of the singleton to be
generated later in step 4.
Step 2 still negotiates TLS, but can fail early if the protocol would
be older than the oldest allowed in the pre-filtered list.
Step 4 takes that pre-filtered list and completes the restriction down to
first entry matching the IP, database, and username. This should be the
same singleton it would generate now. But it can fail-fast if that entry
would require a higher protocol version than what's been negotiated,
before sending the corresponding authentication request message, so no
authentication data will be exchanged over a less-secure channel than
intended. However, the user, database name, and options in the Startup
message might have been exposed over a lower TLS version than intended.
Maybe that's not the end of the world?
Regards,
-Chap