Обсуждение: Periodic authorization expiration checks using GoAway message
This patch introduces a mechanism to address the security issue of stale, authorized connections persisting beyond their validity period. . Currently, once a session is established, postgres does not automatically re-validate credentials. If a password expires (rolvaliduntil) the session remains active indefinitely. Same applies to centralized authentication systems (like Kerberos or OAuth).
This patch depends on the "GoAway" protocol message proposal currently under review here: https://www.postgresql.org/message-id/DDPQ1RV5FE9U.I2WW34NGRD8Z%40jeltef.nl Please apply this patch on top of the GoAway patch.
The Solution: To handle this authorization gap gracefully, this patch leverages the pending GoAway protocol message to notify clients.
Please find below summary of the solution
New GUC: auth_expiration_check_interval (integer, minutes). Controls the frequency of checking a session's authorization status. Setting it to 0 (default) disables the check.
Periodic Idle Check: When a backend process is idle (waiting for the next command) and the timeout is reached, the server calls a placeholder function check_external_auth_status_expired().
Graceful Disconnect: If authorization is revoked/expired, the server sends the GoAway message. This allows the client to finish any current processing and reconnect cleanly.
Thanks & Best Regards,
Ajit Awekar
This patch depends on the "GoAway" protocol message proposal currently under review here: https://www.postgresql.org/message-id/DDPQ1RV5FE9U.I2WW34NGRD8Z%40jeltef.nl Please apply this patch on top of the GoAway patch.
The Solution: To handle this authorization gap gracefully, this patch leverages the pending GoAway protocol message to notify clients.
Please find below summary of the solution
New GUC: auth_expiration_check_interval (integer, minutes). Controls the frequency of checking a session's authorization status. Setting it to 0 (default) disables the check.
Periodic Idle Check: When a backend process is idle (waiting for the next command) and the timeout is reached, the server calls a placeholder function check_external_auth_status_expired().
Graceful Disconnect: If authorization is revoked/expired, the server sends the GoAway message. This allows the client to finish any current processing and reconnect cleanly.
Thanks & Best Regards,
Ajit Awekar
Вложения
On Fri, Nov 28, 2025, 04:39 Ajit Awekar <ajitpostgres@gmail.com> wrote:
This patch depends on the "GoAway" protocol message proposal currently under review here: https://www.postgresql.org/message-id/DDPQ1RV5FE9U.I2WW34NGRD8Z%40jeltef.nl Please apply this patch on top of the GoAway patch.
A review of the GoAway patch from you would definitely be appreciated (even if there's no actionable feedback like: "this looks good and I managed use it for my own patch successfully")
The Solution: To handle this authorization gap gracefully, this patch leverages the pending GoAway protocol message to notify clients.
I didn't look at the patch (I'm on my phone). But my first thought is that only relying on the proposed version of GoAway is insufficient for anything related to security. The GoAway message is both best effort, and only supported with newer protocol versions. So while I think it's a good usecase for GoAway, I think there *also* needs to be a hard timeout at which point the connection gets forcefully terminated if it's using old credentials.
Regarding the configurable interval that you describe for checking auth changes, I think it might be better to register a SysCache update receiver instead (or just poll the SysCache value
Finally, can you register this patch on the commitfest? https://commitfest.postgresql.org/
Also have not looked at the patch, but we should also make sure that there is not just be GoAway, but also a way to re-authenticate or "extend lease" or whatever the terminology is for a specific authentication method. So maybe the message should be ReAuthentiocateOrElse" ? On Fri, Nov 28, 2025 at 6:19 PM Jelte Fennema-Nio <postgres@jeltef.nl> wrote: > > On Fri, Nov 28, 2025, 04:39 Ajit Awekar <ajitpostgres@gmail.com> wrote: >> >> This patch depends on the "GoAway" protocol message proposal currently under review here: https://www.postgresql.org/message-id/DDPQ1RV5FE9U.I2WW34NGRD8Z%40jeltef.nl Please apply this patch on top of the GoAwaypatch. > > > A review of the GoAway patch from you would definitely be appreciated (even if there's no actionable feedback like: "thislooks good and I managed use it for my own patch successfully") > >> The Solution: To handle this authorization gap gracefully, this patch leverages the pending GoAway protocol message tonotify clients. > > > I didn't look at the patch (I'm on my phone). But my first thought is that only relying on the proposed version of GoAwayis insufficient for anything related to security. The GoAway message is both best effort, and only supported with newerprotocol versions. So while I think it's a good usecase for GoAway, I think there *also* needs to be a hard timeoutat which point the connection gets forcefully terminated if it's using old credentials. > > Regarding the configurable interval that you describe for checking auth changes, I think it might be better to registera SysCache update receiver instead (or just poll the SysCache value > > Finally, can you register this patch on the commitfest? https://commitfest.postgresql.org/