Horton

Re: Major Version Upgrade failure due to orphan roles entries in catalog

Tom Lane <tgl@sss.pgh.pa.us>

View thread
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Laurenz Albe <laurenz.albe@cybertec.at>
Cc: Virender Singla <virender.cse@gmail.com>, Robert Haas <robertmhaas@gmail.com>, pgsql-bugs@lists.postgresql.org, Aniket Jha <aniketkumarj@gmail.com>
Date: 2025-02-13T17:07:25Z
Lists: pgsql-bugs

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Avoid race condition between "GRANT role" and "DROP ROLE".

  2. Fix pg_dumpall to cope with dangling OIDs in pg_auth_members.

  3. Ensure that pg_auth_members.grantor is always valid.

Attachments

Laurenz Albe <laurenz.albe@cybertec.at> writes:
> On Tue, 2025-02-11 at 15:32 +0530, Virender Singla wrote:
>> /* Postgres version:: PostgreSQL 16.6 */
>> /* The same can be reproduced in version 17 as well */
>> 
>> create role my_group;
>> create role dropped_member;
>> begin;
>> grant my_group to dropped_member;
>> OTHER SESSION: drop role dropped_member;
>> BACK IN ORIGINAL SESSION:
>> commit;

[ leaves a dangling pg_auth_members entry behind ]

> I guess the GRANT statement should put a FOR KEY SHARE lock on the pg_authid row
> for "dropped_member", similar to what we do for foreign keys.

There is a lock taken already, which is why the DROP ROLE blocks.
What there is not is a recheck that the role still exists once
we have its lock.

I poked into this, and in code terms it seems like the problem is
that AddRoleMems adds a pg_auth_members entry but makes it depend
on only one of the three roles listed in the entry.  That seems
wrong on its face.  The connection to this problem is that the
dependency-adding code would take care of the lock+recheck, if
it only knew that the pg_auth_members entry ought to be treated
as depending on dropped_member.

The code the attached patch is touching is from commit 6566133c5.
I'm not going to blame the bug on that commit, because before that
we had dependencies on *zero* of the three roles; at least it added
one on the grantor.  But I'm wondering whether Robert thought about
the other two roles and explicitly rejected making dependencies
for them, and if so why.

In addition to fixing the described race condition, this patch
means that DROP OWNED BY on either the granted role or the member
will drop the grant.  This seems consistent with the goals of
6566133c5 and with our general approach to dropping privileges
during DROP OWNED BY; but it didn't happen that way before.

I'm wondering a little bit if we could simplify/remove some of the
code in user.c by relying on processing of these dependency entries
to carry the load instead during DROP ROLE.  But it passes check-world
as-is, so maybe leaving well enough alone is best.

			regards, tom lane