From: | Chapman Flack <chap(at)anastigmatix(dot)net> |
---|---|
To: | Magnus Hagander <magnus(at)hagander(dot)net> |
Cc: | Stephen Frost <sfrost(at)snowman(dot)net>, "Bossart, Nathan" <bossartn(at)amazon(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: allow specifying direct role membership in pg_hba.conf |
Date: | 2021-05-17 21:18:07 |
Message-ID: | 60A2DD8F.9090602@anastigmatix.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2021-05-17 21:28:57 | Re: Move pg_attribute.attcompression to earlier in struct for reduced size? |
Previous Message | Tom Lane | 2021-05-17 21:06:32 | Re: Move pg_attribute.attcompression to earlier in struct for reduced size? |