Re: Periodic authorization expiration checks using GoAway message

From: Zsolt Parragi <zsolt(dot)parragi(at)percona(dot)com>
To: Ajit Awekar <ajitpostgres(at)gmail(dot)com>
Cc: Jacob Champion <jacob(dot)champion(at)enterprisedb(dot)com>, Jelte Fennema-Nio <postgres(at)jeltef(dot)nl>, Hannu Krosing <hannuk(at)google(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Dave Cramer <davecramer(at)gmail(dot)com>, Heikki Linnakangas <hlinnaka(at)iki(dot)fi>
Subject: Re: Periodic authorization expiration checks using GoAway message
Date: 2026-02-03 19:16:09
Message-ID: CAN4CZFNB2n1p6v2pZKA1FuR-ssXJLErijkqwjLWwnOQwc=ygPg@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hello!

I did some manual testing of the patch, and found a few more issues / questions.

I think it would be a good idea to add a tap test at this point to
make sure that every corner case works properly.

1. CheckPasswordExpiration doesn't verify that the connection uses
password authentication or not, it always updates the valid date and
starts enforcing it - it should have an additional check at the
beginning to only continue if password_valid_until_timestamp > 0,
otherwise it should just reset AuthCheckNeeded

For example, currently:

* I created a user with a password expiration in the past, logged in
using trust authentication - login worked without problems
* Changed the password expiration of another user, the previous
session got terminated because of the expired password

2. it is triggered if any user gets changed, not just the current user
- on a server with many users, this could be a performance issue as
we'll end up doing unnecessary syscache lookups. This could be
optimized by caching the syscache hash in a variable. (but this is
based on what do you think about the next point)

Again see the previous example problem - I changed the expiration date
of one user, and another user was kicked out because of this, while
that user didn't receive any updates

3. The check is based on GetUserId() and not GetSessionUserId() - if I
change roles with SET ROLE, password expiration checks will verify the
role user, and not the logged in user. This seems strange to me: if we
logged in with a password, after a SET ROLE, we'll enforce password
expiration based on the new role - but we never actually used the
password of that role. Are you sure this is how it should work?

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Jesper Pedersen 2026-02-03 19:21:40 Re: GSoC 2026: Call for Mentors, Project Ideas and Project Idea Reviews
Previous Message Mahendra Singh Thalor 2026-02-03 19:14:37 Re: getting "shell command argument contains a newline or carriage return:" error with pg_dumpall when db name have new line in double quote