Subject: DROP ROLE as SUPERUSER

From: Dominique Devienne <[email-masked]>
Date: Thu, 20 Feb 2025 16:48:20 +0100

Hi. Today I was surprised that REVOKE ALL ON DATABASE FROM ROLE silently
did nothing, even with CASCADE, when I was running it as SUPERUSER,
preventing DROP'ing the ROLE. I had to manually SET ROLE to the GRANTOR, do
the REVOKE, which DID something this time, and then I could DROP the role.

That's hardly convenient :). And I was helping someone else who couldn't
figure out how to drop that role. Isn't there a better way?

I thought SUPERUSER was more powerful that than. Why isn't it?

Thanks, --DD

---

From: "David G. Johnston" <[email-masked]>
Date: Thu, 20 Feb 2025 08:55:21 -0700

> I thought SUPERUSER was more powerful that than. Why isn't it?

This has nothing to do with power/permissions.  It is about not specifying
“granted by” in your SQL command and thus failing to fully and correctly
specify the single permission you want to revoke.

David J.

---

From: "David G. Johnston" <[email-masked]>
Date: Thu, 20 Feb 2025 08:56:47 -0700

> specify the single permission you want to revoke.

Well, not “single permission” but the ALL only applies to the permission
types, not actually everything for all grantors.

David J.

---

From: Tom Lane <[email-masked]>
Date: Thu, 20 Feb 2025 11:05:50 -0500

> specify the single permission you want to revoke.

It used to be that if a superuser issued GRANT/REVOKE, the operation
was silently done as the owner of the affected object.  That was
always a bit of a wart, since among other things it meant that the
object owner could undo it.  Now you have to say "GRANTED BY <owner>"
to get that effect.  I'm not entirely sure, but I think this is closer
to what the SQL standard says.

			regards, tom lane

---

From: "David G. Johnston" <[email-masked]>
Date: Thu, 20 Feb 2025 09:20:54 -0700

On Thu, Feb 20, 2025 at 9:05 AM Tom Lane <[email-masked]> wrote:

> was silently done as the owner of the affected object.
>
That is still the case according to the docs (REVOKE):

"If a superuser chooses to issue a GRANT or REVOKE command, the command is
performed as though it were issued by the owner of the affected object."

The docs seem to be missing reasonable exposition regarding "granted by".
The clause isn't even formally mentioned on the page; though I suppose it
is because it is delegated to the GRANT page specification.  Though the
description there says it is basically an ignored compatibility clause -
not something that a superuser can use to make things more explicit than
using SET ROLE (not sure if it can ATM...).

David J.

---

From: Dominique Devienne <[email-masked]>
Date: Thu, 20 Feb 2025 17:21:13 +0100

> to what the SQL standard says.

I wasn't aware of GRANTED BY, thanks for that.

But that's not much better. It's basically like the SET ROLE to the GRANTOR
I did.
I guess what I want is GRANTED BY ANYONE! And not have to figure out
GRANTOR(s).

Also, note that GRANTOR is not even the owner of the DATABASE in my case.
--DD

---

From: "David G. Johnston" <[email-masked]>
Date: Thu, 20 Feb 2025 09:29:40 -0700

On Thu, Feb 20, 2025 at 9:21 AM Dominique Devienne <[email-masked]>
wrote:

> But that's not much better. It's basically like the SET ROLE to the
> GRANTOR I did.

Your stated use case is dropping a role.  Does the combination of reassign
and drop owned not fulfill the requirements?

https://www.postgresql.org/docs/current/role-removal.html

Also, you had to know the role you wanted to drop so you already figured
out the grantor.

David J.

---

From: Tom Lane <[email-masked]>
Date: Thu, 20 Feb 2025 11:52:18 -0500

> That is still the case according to the docs (REVOKE):

[ scratches head ... ]  I thought we had changed that, but nope I'm wrong:

regression=# create user alice;
CREATE ROLE
regression=# create user bob;
CREATE ROLE
regression=# \c - alice
You are now connected to database "regression" as user "alice".
regression=> create table alices_table (f1 int);
CREATE TABLE
regression=> grant select on alices_table to bob;
GRANT
regression=> \dp alices_table
                                  Access privileges
 Schema |     Name     | Type  |  Access privileges   | Column privileges | Policies 
--------+--------------+-------+----------------------+-------------------+----------
 public | alices_table | table | alice=arwdDxtm/alice+|                   | 
        |              |       | bob=r/alice          |                   | 
(1 row)

regression=> \c - postgres
You are now connected to database "regression" as user "postgres".
regression=# grant update on alices_table to bob;
GRANT
regression=# \dp alices_table
                                  Access privileges
 Schema |     Name     | Type  |  Access privileges   | Column privileges | Policies 
--------+--------------+-------+----------------------+-------------------+----------
 public | alices_table | table | alice=arwdDxtm/alice+|                   | 
        |              |       | bob=rw/alice         |                   | 
(1 row)

regression=# revoke update on alices_table from bob;
REVOKE
regression=# \dp alices_table
                                  Access privileges
 Schema |     Name     | Type  |  Access privileges   | Column privileges | Policies 
--------+--------------+-------+----------------------+-------------------+----------
 public | alices_table | table | alice=arwdDxtm/alice+|                   | 
        |              |       | bob=r/alice          |                   | 
(1 row)

regression=# revoke select on alices_table from bob;
REVOKE
regression=# \dp alices_table
                                  Access privileges
 Schema |     Name     | Type  |  Access privileges   | Column privileges | Policies 
--------+--------------+-------+----------------------+-------------------+----------
 public | alices_table | table | alice=arwdDxtm/alice |                   | 
(1 row)

So grants and revokes are still being done as the object owner by
default.

Now I'm unclear on exactly what was happening in Dominique's case.
Was the problematic permission granted by somebody other than the
database's owner?

			regards, tom lane