Обсуждение: Add "host" to startup packet
Hello,
Patch attached below. TLDR, I'd like to add "host" to the startup packet.
I'm trying to run multiple Postgres servers in a multi-tenant environment behind a pooler. Currently, the only way to differentiate Postgres databases is with the user/dbname combination which are very often included in the startup packet by the client. However, that's not sufficient if you have users that all want to have the user "admin" and the database "production" :)
HTTP hosting providers solved this using the "Host" header, allowing the server to identify which website the client wants. In the case of Postgres, this is the DNS or IP address, depending on the client configuration.
Upon receiving a startup packet with user, dbname, and host, the pooler (acting also as a proxy) can validate that the credentials exist for the host and that they are valid, and authorize or decline the connection.
I have never submitted a patch for Postgres before, so I'm not entirely sure how to test this change, although it seems pretty harmless. Any feedback and help are appreciated!
Thank you!
Best,
Lev
Вложения
Lev Kokotov <lev@hyperparam.ai> writes:
> Patch attached below. TLDR, I'd like to add "host" to the startup packet.
I don't think this is of any use at all in isolation. What is the server
going to do with it? What's your plan for persuading clients other than
libpq to supply it? How are poolers supposed to handle it? What will
you do about old clients that don't supply it? And most importantly,
how can a client know while connecting whether it's safe to include this,
realizing that existing servers will error out (they'll think it's a
GUC setting for "host")?
Even if all that infrastructure sprang into existence, is this really any
more useful than basing your switching on the host's resolved IP address?
I'm doubtful that there's enough win there to justify pushing this rock
to the top of the mountain.
regards, tom lane
On Sun, 2 Apr 2023 at 11:38, Tom Lane <tgl@sss.pgh.pa.us> wrote: > > Even if all that infrastructure sprang into existence, is this really any > more useful than basing your switching on the host's resolved IP address? > I'm doubtful that there's enough win there to justify pushing this rock > to the top of the mountain. Hm. I think it's going to turn out to be useful. Experience shows depending on the ip address often paints people into corners. However I agree that we need to actually have a real use case in hand where someone is going to actually do something with it. My question is a bit different. How does this interact with TLS SNI. Can you just use the SNI name given in the TLS handshake? Should the server require them to match? Is there any value to having a separate source for this info? Is something similar available in GSSAPI authentication? -- greg
Greg Stark <stark@mit.edu> writes:
> My question is a bit different. How does this interact with TLS SNI.
> Can you just use the SNI name given in the TLS handshake? Should the
> server require them to match? Is there any value to having a separate
> source for this info? Is something similar available in GSSAPI
> authentication?
The idea that I was thinking about was to not hard-wire sending the host
string exactly, but instead to invent another connection parameter along
the line of "send_host = name-to-send". This parallels the situation in
HTTP where the "Host" header doesn't necessarily have to match the actual
transport target. I can think of a couple of benefits:
* Avoid breaking backward compatibility with old servers: if user doesn't
add this option then nothing extra is sent.
* Separating the send_host name would simplify testing scenarios.
Seems like it would depend a lot on your use-case whether you care about
the send_host name matching anything that's authenticated. If you do,
there's a whole lot more infrastructure to build out around pg_hba.conf.
Right now that file is designed on the assumption that it describes
authentication rules for a single "host", but we'd need to generalize
it to describe rules for multiple host values.
regards, tom lane
> On 2 Apr 2023, at 18:33, Tom Lane <tgl@sss.pgh.pa.us> wrote: > > Greg Stark <stark@mit.edu> writes: >> My question is a bit different. How does this interact with TLS SNI. >> Can you just use the SNI name given in the TLS handshake? Should the >> server require them to match? Is there any value to having a separate >> source for this info? Is something similar available in GSSAPI >> authentication? > > The idea that I was thinking about was to not hard-wire sending the host > string exactly, but instead to invent another connection parameter along > the line of "send_host = name-to-send". This parallels the situation in > HTTP where the "Host" header doesn't necessarily have to match the actual > transport target. Since we already have sslsni in libpq since v14, any SNI being well understood and standardized, do we really want to invent our own parallel scheme? Alternatively, the protocol in the.PROXY patch by Magnus [0] which stalled a few CF's ago has similar functionality for the client to pass a hostname. -- Daniel Gustafsson [0] https://www.postgresql.org/message-id/flat/CABUevExJ0ifpUEiX4uOREy0s2kHBrBrb=pXLEHhpMTR1vVR1XA@mail.gmail.com