Date: Tue, 5 May 2026 14:40:49 -0500
From: Nathan Bossart <nathandbossart@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Euler Taveira <euler@eulerto.com>,
	=?utf-8?B?w4FsdmFybyBSb2Ryw61ndWV6?= <alvaro@datadoghq.com>,
	pgsql-bugs@lists.postgresql.org,
	Javier Maellas <javier.maellas@datadoghq.com>,
	Diego Revenga <diego.revengagonzalez@datadoghq.com>,
	robertmhaas@gmail.com
Subject: Re: pg_dumpall can't be restored with different bootstrap superuser
Message-ID: <afpHwTR1IJypF1md@nathan>
References: <CA+C_kKWHMP4c56jx1BPvP1jmjp2pmBu0Cw07fPVECUmkJSnT4w@mail.gmail.com>
 <fb3f446c-3a5e-40c0-82da-18ce6b81926b@app.fastmail.com>
 <671134.1778008247@sss.pgh.pa.us>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <671134.1778008247@sss.pgh.pa.us>
Archived-At: <https://www.postgresql.org/message-id/afpHwTR1IJypF1md%40nathan>
Precedence: bulk

On Tue, May 05, 2026 at 03:10:47PM -0400, Tom Lane wrote:
> I don't think that pg_dumpall is to be blamed; this is the backend's
> fault.  I thought we had made this better in dd1398f13, but it still
> seems rather bogus:
> 
> [...]
> regression=# grant a to b granted by super;
> ERROR:  permission denied to grant privileges as role "super"
> DETAIL:  The grantor must have the ADMIN option on role "a".
> 
> Surely a superuser should be considered to have admin options
> on everything.

I think this comes from commit ce6b672e44, which established the idea that
the bootstrap superuser was the "role owner".

> Even more bogus, compare these results:
> 
> regression=# \c - super
> You are now connected to database "regression" as user "super".
> regression=# grant a to b granted by super;
> ERROR:  permission denied to grant privileges as role "super"
> DETAIL:  The grantor must have the ADMIN option on role "a".
> 
> regression=# grant a to b;
> GRANT ROLE
> 
> Anyone would think that "GRANTED BY current_user" has the
> same effect as omitting the clause, but here it doesn't.

Right.  When omitted, check_role_grantor() uses the bootstrap superuser if
the current role is a superuser.

> So it seems to me that we're missing a superuserness check
> somewhere in this, but I'm not entirely sure which bit of
> code to blame.
> 
> I agree that the answer for existing branches is probably
> going to be "so don't do that", but maybe we can improve
> this in v19 or later.

I've added Robert to the thread for his thoughts.  I'm not sure how much
wiggle room we have in the current design to make things more lenient, but
I haven't investigated too deeply yet.

-- 
nathan