Hi,
After multiple years, I retried to work on this feature again and, this
time, I finally did it.
As I could not rebase your patch Magnus, I decided to restart from
scratch, with all this thread history in mind and what was in my head too.
The first change drifting from the initial implementation is this patch
uses the same port for both proxy protocol aware connections and for not
proxy protocol aware connections. To follow the spec, if a connection
comes from a trusted network but doesn't provide the PROXY header, the
server will reject it. Having only one port to listen is simpler from an
operator point of view. No need to configure and document more
networking rules. Existing rules will work as usual.
I wanted this patch to be as transparent as possible so the protocol is
parsed at the very end to let a chance for existing parsing rules to be
executed before the proxy protocol. No performance regression expected,
unless you enable the feature by configuring a list of proxy networks or
if your connection is not valid but this should be insignificant.
There is one exception for direct SSL though. The spec precises that any
proxy connection must provide the header, but this is not the case for
direct SSL. The fix is small. I have included the SSL handling in the
proxy protocol parsing. No change of behavior, no major code
refactoring. Let me know if you have a better implementation.
As a security measure, an untrusted connection, not in the trusted proxy
networks, that doesn't provide the header is rejected with the generic
"incomplete startup packet" message instead of an explicit proxy error.
This prevent untrusted clients, possibly scanning the service, to
discover that the server supports the proxy protocol.
The patch supports both v1 and v2 versions of the protocol. If a
connection is trusted and valid, the client_addr, hostname and port are
replaced by the ones provided in the proxy header in pg_stat_activity.
The original values are available in proxy_addr, hostname and port. The
pg_hba.conf uses the parsed client information, which is the goal of
this feature. But also, both the parsed client and proxy information are
added to the loggers (stderr, csvlog and jsonlog).
All those changes are tested in a protocol TAP tests suite. I wanted
them to be as readable as possible, so excuse me if they are not
straightforward. I could not find helpers to wait and parse csvlog and
jsonlog loggers so I have created them in the protocol suite. These
functions are not aware of the format so they wait and return a line
matching a regex. I could make them format aware to wait for CSV or JSON
field and values to show up. This patch is already big so let me know if
you want me to add those helpers in the test libraries now or in a
future patch.
I hope you'll find this patch useful.
Have a nice day,
--
Julien
