public inbox for pgsql-sql@postgresql.org
help / color / mirror / Atom feedRevoke Connect Privilege from Database not working
18+ messages / 4 participants
[nested] [flat]
* Revoke Connect Privilege from Database not working
@ 2025-03-31 15:26 Ing. Marijo Kristo <marijo.kristo@icloud.com>
2025-04-01 14:13 ` Re: Revoke Connect Privilege from Database not working Tom Lane <tgl@sss.pgh.pa.us>
2025-04-01 14:15 ` Re: Revoke Connect Privilege from Database not working David G. Johnston <david.g.johnston@gmail.com>
0 siblings, 2 replies; 18+ messages in thread
From: Ing. Marijo Kristo @ 2025-03-31 15:26 UTC (permalink / raw)
To: pgsql-sql@lists.postgresql.org
> Hello,
>
> we are using Vault to provision temporary users which get deleted after a
> while by the same user.
> For this purpose we have created a vault_admin user.
>
> postgres=# \du vault_admin
> List of roles
> Role name | Attributes
> -------------+------------------------
> vault_admin | Superuser, Create role
>
> postgres=# \l "disp_db"
>
> List of databases
> Name | Owner | Encoding | Locale Provider | Collate |
> Ctype | ICU Locale | ICU Rules | Access
> privileges
> ---------+-------------------+----------+-----------------+------------+------------+------------+-----------+--------------------------------------------------------------------------------
> disp_db | app_disp_db_admin | UTF8 | libc | en_US.utf8 |
> en_US.utf8 | | |
> app_disp_db_admin=CTc/app_disp_db_admin
> +
> | | | | |
> | | | app_disp_db=Tc/app_disp_db_admin
> +
> | | | | |
> | | | pg_database_owner=CTc/app_disp_db_admin
> +
> | | | | |
> | | | vault_admin=c*/app_disp_db_admin
> +
> | | | | |
> | | |
> "dev_oidc-m-kristo-rewe-group-at-2025_02_28T09_06_30+00:00"=c/vault_admin
> +
> | | | | |
> | | | app_disp_db_readonly=c/app_disp_db_admin
>
>
> Removing the connect privilege with the Postgres Superuser and with the
> Vault Admin user does not work.
>
> postgres=# select current_user;
> current_user
> --------------
> postgres
>
> postgres=# revoke connect on database "disp_db" from
> "dev_oidc-m-kristo-rewe-group-at-2025_02_28T09_06_30+00:00";
> REVOKE
>
> postgres=# drop user
> "dev_oidc-m-kristo-rewe-group-at-2025_02_28T09_06_30+00:00";
> ERROR: role "dev_oidc-m-kristo-rewe-group-at-2025_02_28T09_06_30+00:00"
> cannot be dropped because some objects depend on it
> DETAIL: privileges for database disp_db
>
> Same happens when trying to revoke with the vault admin user:
>
> disp_db=# select current_user;
> current_user
> --------------
> vault_admin
> (1 row)
>
> disp_db=# revoke connect on database "disp_db" from
> "dev_oidc-m-kristo-rewe-group-at-2025_02_28T09_06_30+00:00";
> REVOKE
> disp_db=# drop user
> "dev_oidc-m-kristo-rewe-group-at-2025_02_28T09_06_30+00:00";
> ERROR: role "dev_oidc-m-kristo-rewe-group-at-2025_02_28T09_06_30+00:00"
> cannot be dropped because some objects depend on it
> DETAIL: privileges for database disp_db
>
> Does not work via PSQL nor with pgadmin.
>
> Best Regards
> Marijo Kristo
>
^ permalink raw reply [nested|flat] 18+ messages in thread
* Re: Revoke Connect Privilege from Database not working
2025-03-31 15:26 Revoke Connect Privilege from Database not working Ing. Marijo Kristo <marijo.kristo@icloud.com>
@ 2025-04-01 14:13 ` Tom Lane <tgl@sss.pgh.pa.us>
1 sibling, 0 replies; 18+ messages in thread
From: Tom Lane @ 2025-04-01 14:13 UTC (permalink / raw)
To: Ing. Marijo Kristo <marijo.kristo@icloud.com>; +Cc: pgsql-sql@lists.postgresql.org
"Ing. Marijo Kristo" <marijo.kristo@icloud.com> writes:
>> Removing the connect privilege with the Postgres Superuser and with the
>> Vault Admin user does not work.
>> postgres=# revoke connect on database "disp_db" from
>> "dev_oidc-m-kristo-rewe-group-at-2025_02_28T09_06_30+00:00";
>> REVOKE
REVOKE is not being as helpful as it could be here, perhaps:
it is failing to tell you that it's a no-op because there
is no such privilege. You never granted connect on disp_db
to that user so you can't revoke it either.
The privilege that exists by default, per [1], is that
database connect privileges are granted to PUBLIC (the
pseudo-group of all users). If that's not what you want,
you have to do
revoke connect on database "disp_db" from public;
and then grant it out again to the users who should have it.
regards, tom lane
[1] https://www.postgresql.org/docs/current/ddl-priv.html
^ permalink raw reply [nested|flat] 18+ messages in thread
* Re: Revoke Connect Privilege from Database not working
2025-03-31 15:26 Revoke Connect Privilege from Database not working Ing. Marijo Kristo <marijo.kristo@icloud.com>
@ 2025-04-01 14:15 ` David G. Johnston <david.g.johnston@gmail.com>
1 sibling, 0 replies; 18+ messages in thread
From: David G. Johnston @ 2025-04-01 14:15 UTC (permalink / raw)
To: Ing. Marijo Kristo <marijo.kristo@icloud.com>; +Cc: pgsql-sql@lists.postgresql.org
On Tue, Apr 1, 2025 at 4:59 AM Ing. Marijo Kristo <marijo.kristo@icloud.com>
wrote:
>
> >
> "dev_oidc-m-kristo-rewe-group-at-2025_02_28T09_06_30+00:00"=c/vault_admin
>
> > Same happens when trying to revoke with the vault admin user:
> >
> > disp_db=# select current_user;
> > current_user
> > --------------
> > vault_admin
> > (1 row)
> >
> > disp_db=# revoke connect on database "disp_db" from
> > "dev_oidc-m-kristo-rewe-group-at-2025_02_28T09_06_30+00:00";
> > REVOKE
> > disp_db=# drop user
> > "dev_oidc-m-kristo-rewe-group-at-2025_02_28T09_06_30+00:00";
> > ERROR: role "dev_oidc-m-kristo-rewe-group-at-2025_02_28T09_06_30+00:00"
> > cannot be dropped because some objects depend on it
> > DETAIL: privileges for database disp_db
>
>
If you include the "granted by" clause when you perform revoke everything
usually just works.
"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." [1]
The fact vault_admin is superuser overrides the fact that it is their
specific grant that is trying to be revoked.
David J.
[1] https://www.postgresql.org/docs/current/sql-revoke.html
^ permalink raw reply [nested|flat] 18+ messages in thread
* Re: Re: Revoke Connect Privilege from Database not working
@ 2025-04-07 13:42 David G. Johnston <david.g.johnston@gmail.com>
2025-04-07 14:27 ` Aw: Re: Re: Revoke Connect Privilege from Database not working Ing. Marijo Kristo <marijo.kristo@icloud.com>
0 siblings, 1 reply; 18+ messages in thread
From: David G. Johnston @ 2025-04-07 13:42 UTC (permalink / raw)
To: Ing. Marijo Kristo <marijo.kristo@icloud.com>; +Cc: pgsql-sql@lists.postgresql.org <pgsql-sql@lists.postgresql.org>
On Monday, April 7, 2025, Ing. Marijo Kristo <marijo.kristo@icloud.com>
wrote:
>
>
> Seems like a bug to me.
> Can someone else verifiy this ?
>
It would help greatly if you create a reproducer that starts from a clean
install, creates the roles and database, and demonstrates the issue.
> postgres=# \du vault_admin;
> List of roles
> Role name | Attributes
> -------------+------------------------
> vault_admin | Superuser, Create role
>
> postgres=# set role vault_admin;
>
You are setting role to another role that has superuser which is basically
pointless.
Use “granted by” in your revoke command. If that works this isn’t a bug.
David J.
^ permalink raw reply [nested|flat] 18+ messages in thread
* Aw: Re: Re: Revoke Connect Privilege from Database not working
2025-04-07 13:42 Re: Re: Revoke Connect Privilege from Database not working David G. Johnston <david.g.johnston@gmail.com>
@ 2025-04-07 14:27 ` Ing. Marijo Kristo <marijo.kristo@icloud.com>
2025-04-07 15:37 ` Re: Re: Re: Revoke Connect Privilege from Database not working David G. Johnston <david.g.johnston@gmail.com>
0 siblings, 1 reply; 18+ messages in thread
From: Ing. Marijo Kristo @ 2025-04-07 14:27 UTC (permalink / raw)
To: David G. Johnston <david.g.johnston@gmail.com>; +Cc: pgsql-sql@lists.postgresql.org <pgsql-sql@lists.postgresql.org>
Hi, here is a full reproducer. Also revoking with the granted by clause does not work. #clean initialization postgres=# create database testdb owner postgres; CREATE DATABASE postgres=# create user test_admin createrole; CREATE ROLE postgres=# alter user test_admin with password 'test1234'; ALTER ROLE postgres=# grant connect on database testdb to test_admin with grant option; GRANT #create user and grant connect privilege with test_admin postgres=# set role test_admin; SET postgres=> create user test_user password 'testuserpw'; CREATE ROLE postgres=> grant connect on database testdb to test_user; GRANT #generate the failure by granting test_admin superuser privileges postgres=> reset role; RESET postgres=# alter user test_admin superuser; ALTER ROLE postgres=# set role test_admin; SET postgres=# revoke connect on database testdb from test_user; REVOKE postgres=# drop user test_user; ERROR: role "test_user" cannot be dropped because some objects depend on it DETAIL: privileges for database testdb #test also with "granted by clause" postgres=# revoke connect on database testdb from test_user granted by "test_admin"; REVOKE postgres=# drop user test_user; ERROR: role "test_user" cannot be dropped because some objects depend on it DETAIL: privileges for database testdb #fix by removing superuser privilege from test_admin postgres=# reset role; RESET postgres=# alter user test_admin nosuperuser; ALTER ROLE postgres=# set role test_admin; SET postgres=> revoke connect on database testdb from test_user; REVOKE postgres=> drop role test_user; DROP ROLE Best Regards Marijo Kristo David G. Johnston <david.g.johnston@gmail.com> schrieb am 7. Apr. 2025 um 15:42: On Monday, April 7, 2025, Ing. Marijo Kristo < marijo.kristo@icloud.com > wrote: Seems like a bug to me. Can someone else verifiy this ? It would help greatly if you create a reproducer that starts from a clean install, creates the roles and database, and demonstrates the issue. postgres=# \du vault_admin; List of roles Role name | Attributes -------------+---------------- -------- vault_admin | Superuser, Create role postgres=# set role vault_admin; You are setting role to another role that has superuser which is basically pointless. Use “granted by” in your revoke command. If that works this isn’t a bug. David J.
^ permalink raw reply [nested|flat] 18+ messages in thread
* Re: Re: Re: Revoke Connect Privilege from Database not working
2025-04-07 13:42 Re: Re: Revoke Connect Privilege from Database not working David G. Johnston <david.g.johnston@gmail.com>
2025-04-07 14:27 ` Aw: Re: Re: Revoke Connect Privilege from Database not working Ing. Marijo Kristo <marijo.kristo@icloud.com>
@ 2025-04-07 15:37 ` David G. Johnston <david.g.johnston@gmail.com>
2025-04-07 16:06 ` Re: Re: Re: Revoke Connect Privilege from Database not working Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 1 reply; 18+ messages in thread
From: David G. Johnston @ 2025-04-07 15:37 UTC (permalink / raw)
To: Ing. Marijo Kristo <marijo.kristo@icloud.com>; PostgreSQL Bug List <pgsql-bugs@lists.postgresql.org>
On Mon, Apr 7, 2025 at 7:27 AM Ing. Marijo Kristo <marijo.kristo@icloud.com>
wrote:
> Hi,
> here is a full reproducer. Also revoking with the granted by clause does
> not work.
>
> #clean initialization
> postgres=# create database testdb owner postgres;
> CREATE DATABASE
> postgres=# create user test_admin createrole;
> CREATE ROLE
> postgres=# alter user test_admin with password 'test1234';
> ALTER ROLE
> postgres=# grant connect on database testdb to test_admin with grant
> option;
> GRANT
>
> #create user and grant connect privilege with test_admin
> postgres=# set role test_admin;
> SET
> postgres=> create user test_user password 'testuserpw';
> CREATE ROLE
> postgres=> grant connect on database testdb to test_user;
> GRANT
>
> #generate the failure by granting test_admin superuser privileges
> postgres=> reset role;
> RESET
> postgres=# alter user test_admin superuser;
> ALTER ROLE
> postgres=# set role test_admin;
> SET
> postgres=# revoke connect on database testdb from test_user;
> REVOKE
> postgres=# drop user test_user;
> ERROR: role "test_user" cannot be dropped because some objects depend on
> it
> DETAIL: privileges for database testdb
>
> #test also with "granted by clause"
> postgres=# revoke connect on database testdb from test_user granted by
> "test_admin";
> REVOKE
>
On master, confirmed that after this command the privilege:
test_user=c/test_admin (on database testdb) still exists. That seems like
a bug. Its at least a POLA violation and I cannot figure out how to read
the revoke reference page in a way that explains it.
David J.
# revokescript.psql
create database testdb:v;
create user test_admin:v createrole;
grant connect on database testdb:v to test_admin:v with grant option;
set role test_admin:v;
create user test_user:v password 'testuserpw';
grant connect on database testdb:v to test_user:v;
reset role;
alter user test_admin:v superuser;
set role test_admin:v;
revoke connect on database testdb:v from test_user:v granted by
test_admin:v;
\l+ testdb:v
drop user test_user:v;
> psql postgres --file revokescript.psql -v v=1
^ permalink raw reply [nested|flat] 18+ messages in thread
* Re: Re: Re: Revoke Connect Privilege from Database not working
2025-04-07 13:42 Re: Re: Revoke Connect Privilege from Database not working David G. Johnston <david.g.johnston@gmail.com>
2025-04-07 14:27 ` Aw: Re: Re: Revoke Connect Privilege from Database not working Ing. Marijo Kristo <marijo.kristo@icloud.com>
2025-04-07 15:37 ` Re: Re: Re: Revoke Connect Privilege from Database not working David G. Johnston <david.g.johnston@gmail.com>
@ 2025-04-07 16:06 ` Tom Lane <tgl@sss.pgh.pa.us>
2025-04-07 16:22 ` Re: Re: Re: Revoke Connect Privilege from Database not working David G. Johnston <david.g.johnston@gmail.com>
0 siblings, 1 reply; 18+ messages in thread
From: Tom Lane @ 2025-04-07 16:06 UTC (permalink / raw)
To: David G. Johnston <david.g.johnston@gmail.com>; +Cc: Ing. Marijo Kristo <marijo.kristo@icloud.com>; PostgreSQL Bug List <pgsql-bugs@lists.postgresql.org>
"David G. Johnston" <david.g.johnston@gmail.com> writes:
> On master, confirmed that after this command the privilege:
> test_user=c/test_admin (on database testdb) still exists. That seems like
> a bug. Its at least a POLA violation and I cannot figure out how to read
> the revoke reference page in a way that explains it.
I believe what's going on there is explained by the rule that
"grants and revokes done by a superuser are done as if issued
by the object owner". So here, what would be revoked is
test_user=c/postgres, which isn't the privilege at issue.
Include GRANTED BY in the REVOKE to override the default
choice of grantor.
IIRC, said rule was invented before we had the GRANTED BY
syntax. It probably doesn't make as much sense today,
but I'd be very afraid of breaking peoples' work flows
by changing it.
regards, tom lane
^ permalink raw reply [nested|flat] 18+ messages in thread
* Re: Re: Re: Revoke Connect Privilege from Database not working
2025-04-07 13:42 Re: Re: Revoke Connect Privilege from Database not working David G. Johnston <david.g.johnston@gmail.com>
2025-04-07 14:27 ` Aw: Re: Re: Revoke Connect Privilege from Database not working Ing. Marijo Kristo <marijo.kristo@icloud.com>
2025-04-07 15:37 ` Re: Re: Re: Revoke Connect Privilege from Database not working David G. Johnston <david.g.johnston@gmail.com>
2025-04-07 16:06 ` Re: Re: Re: Revoke Connect Privilege from Database not working Tom Lane <tgl@sss.pgh.pa.us>
@ 2025-04-07 16:22 ` David G. Johnston <david.g.johnston@gmail.com>
2025-11-13 16:47 ` Re: Re: Re: Revoke Connect Privilege from Database not working Nathan Bossart <nathandbossart@gmail.com>
0 siblings, 1 reply; 18+ messages in thread
From: David G. Johnston @ 2025-04-07 16:22 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: Ing. Marijo Kristo <marijo.kristo@icloud.com>; PostgreSQL Bug List <pgsql-bugs@lists.postgresql.org>
On Mon, Apr 7, 2025 at 9:06 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> "David G. Johnston" <david.g.johnston@gmail.com> writes:
> > On master, confirmed that after this command the privilege:
> > test_user=c/test_admin (on database testdb) still exists. That seems
> like
> > a bug. Its at least a POLA violation and I cannot figure out how to read
> > the revoke reference page in a way that explains it.
>
> I believe what's going on there is explained by the rule that
> "grants and revokes done by a superuser are done as if issued
> by the object owner". So here, what would be revoked is
> test_user=c/postgres, which isn't the privilege at issue.
> Include GRANTED BY in the REVOKE to override the default
> choice of grantor.
>
The command in question did include "granted by" which is why this is a
bug. The explicit granted by specification is being ignored if the
invoking user is a superuser.
revoke connect on database testdb:v
from test_user:v
---------------
granted by test_admin:v;
---^^^^^^^^^
So if we stick with status quo behavior we'd need to write the following
because the ignoring part is a POLA violation:
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, and
the granted by clause is ignored.
David J.
^ permalink raw reply [nested|flat] 18+ messages in thread
* Re: Re: Re: Revoke Connect Privilege from Database not working
2025-04-07 13:42 Re: Re: Revoke Connect Privilege from Database not working David G. Johnston <david.g.johnston@gmail.com>
2025-04-07 14:27 ` Aw: Re: Re: Revoke Connect Privilege from Database not working Ing. Marijo Kristo <marijo.kristo@icloud.com>
2025-04-07 15:37 ` Re: Re: Re: Revoke Connect Privilege from Database not working David G. Johnston <david.g.johnston@gmail.com>
2025-04-07 16:06 ` Re: Re: Re: Revoke Connect Privilege from Database not working Tom Lane <tgl@sss.pgh.pa.us>
2025-04-07 16:22 ` Re: Re: Re: Revoke Connect Privilege from Database not working David G. Johnston <david.g.johnston@gmail.com>
@ 2025-11-13 16:47 ` Nathan Bossart <nathandbossart@gmail.com>
2026-01-20 23:05 ` Re: Revoke Connect Privilege from Database not working Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 1 reply; 18+ messages in thread
From: Nathan Bossart @ 2025-11-13 16:47 UTC (permalink / raw)
To: David G. Johnston <david.g.johnston@gmail.com>; +Cc: Tom Lane <tgl@sss.pgh.pa.us>; Ing. Marijo Kristo <marijo.kristo@icloud.com>; PostgreSQL Bug List <pgsql-bugs@lists.postgresql.org>
On Mon, Apr 07, 2025 at 09:22:45AM -0700, David G. Johnston wrote:
> On Mon, Apr 7, 2025 at 9:06 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> I believe what's going on there is explained by the rule that
>> "grants and revokes done by a superuser are done as if issued
>> by the object owner". So here, what would be revoked is
>> test_user=c/postgres, which isn't the privilege at issue.
>> Include GRANTED BY in the REVOKE to override the default
>> choice of grantor.
>
> The command in question did include "granted by" which is why this is a
> bug. The explicit granted by specification is being ignored if the
> invoking user is a superuser.
This is admittedly a half-formed idea, but perhaps we could have whatever's
specified in GRANTED BY override select_best_grantor(), like in the
attached patch. I've no idea if this is the intention of the standard, but
it should at least address the reported issue. FWIW I recently received an
independent report about the same thing.
--
nathan
^ permalink raw reply [nested|flat] 18+ messages in thread
* Re: Revoke Connect Privilege from Database not working
2025-04-07 13:42 Re: Re: Revoke Connect Privilege from Database not working David G. Johnston <david.g.johnston@gmail.com>
2025-04-07 14:27 ` Aw: Re: Re: Revoke Connect Privilege from Database not working Ing. Marijo Kristo <marijo.kristo@icloud.com>
2025-04-07 15:37 ` Re: Re: Re: Revoke Connect Privilege from Database not working David G. Johnston <david.g.johnston@gmail.com>
2025-04-07 16:06 ` Re: Re: Re: Revoke Connect Privilege from Database not working Tom Lane <tgl@sss.pgh.pa.us>
2025-04-07 16:22 ` Re: Re: Re: Revoke Connect Privilege from Database not working David G. Johnston <david.g.johnston@gmail.com>
2025-11-13 16:47 ` Re: Re: Re: Revoke Connect Privilege from Database not working Nathan Bossart <nathandbossart@gmail.com>
@ 2026-01-20 23:05 ` Tom Lane <tgl@sss.pgh.pa.us>
2026-01-21 15:28 ` Re: Revoke Connect Privilege from Database not working Nathan Bossart <nathandbossart@gmail.com>
0 siblings, 1 reply; 18+ messages in thread
From: Tom Lane @ 2026-01-20 23:05 UTC (permalink / raw)
To: Nathan Bossart <nathandbossart@gmail.com>; +Cc: David G. Johnston <david.g.johnston@gmail.com>; Ing. Marijo Kristo <marijo.kristo@icloud.com>; PostgreSQL Bug List <pgsql-bugs@lists.postgresql.org>
Nathan Bossart <nathandbossart@gmail.com> writes:
> This is admittedly a half-formed idea, but perhaps we could have whatever's
> specified in GRANTED BY override select_best_grantor(), like in the
> attached patch. I've no idea if this is the intention of the standard, but
> it should at least address the reported issue. FWIW I recently received an
> independent report about the same thing.
Motivated by the discussion at [1], I'd started on the same idea,
but arrived at a rather different refactorization. I think this
way is nicer (less duplicated logic). Either way, we need to
address the docs and probably add more regression tests.
regards, tom lane
[1] https://www.postgresql.org/message-id/flat/85cd06c6-7b2e-483e-b05d-d5ff87b0168d%40garret.ru
Attachments:
[text/x-diff] v2-0001-GRANTED-BY.patch (8.4K, 2-v2-0001-GRANTED-BY.patch)
download | inline diff:
diff --git a/src/backend/catalog/aclchk.c b/src/backend/catalog/aclchk.c
index a431fc0926f..e31d22ebf7d 100644
--- a/src/backend/catalog/aclchk.c
+++ b/src/backend/catalog/aclchk.c
@@ -98,6 +98,7 @@ typedef struct
AclMode privileges;
List *grantees;
bool grant_option;
+ RoleSpec *grantor;
DropBehavior behavior;
} InternalDefaultACL;
@@ -395,22 +396,6 @@ ExecuteGrantStmt(GrantStmt *stmt)
const char *errormsg;
AclMode all_privileges;
- if (stmt->grantor)
- {
- Oid grantor;
-
- grantor = get_rolespec_oid(stmt->grantor, false);
-
- /*
- * Currently, this clause is only for SQL compatibility, not very
- * interesting otherwise.
- */
- if (grantor != GetUserId())
- ereport(ERROR,
- (errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
- errmsg("grantor must be current user")));
- }
-
/*
* Turn the regular GrantStmt into the InternalGrant form.
*/
@@ -438,6 +423,7 @@ ExecuteGrantStmt(GrantStmt *stmt)
istmt.col_privs = NIL; /* may get filled below */
istmt.grantees = NIL; /* filled below */
istmt.grant_option = stmt->grant_option;
+ istmt.grantor = stmt->grantor;
istmt.behavior = stmt->behavior;
/*
@@ -960,6 +946,7 @@ ExecAlterDefaultPrivilegesStmt(ParseState *pstate, AlterDefaultPrivilegesStmt *s
/* privileges to be filled below */
iacls.grantees = NIL; /* filled below */
iacls.grant_option = action->grant_option;
+ iacls.grantor = action->grantor;
iacls.behavior = action->behavior;
/*
@@ -1486,6 +1473,7 @@ RemoveRoleFromObjectACL(Oid roleid, Oid classid, Oid objid)
iacls.privileges = ACL_NO_RIGHTS;
iacls.grantees = list_make1_oid(roleid);
iacls.grant_option = false;
+ iacls.grantor = NULL;
iacls.behavior = DROP_CASCADE;
/* Do it */
@@ -1542,6 +1530,7 @@ RemoveRoleFromObjectACL(Oid roleid, Oid classid, Oid objid)
istmt.col_privs = NIL;
istmt.grantees = list_make1_oid(roleid);
istmt.grant_option = false;
+ istmt.grantor = NULL;
istmt.behavior = DROP_CASCADE;
ExecGrantStmt_oids(&istmt);
@@ -1696,7 +1685,7 @@ ExecGrant_Attribute(InternalGrant *istmt, Oid relOid, const char *relname,
merged_acl = aclconcat(old_rel_acl, old_acl);
/* Determine ID to do the grant as, and available grant options */
- select_best_grantor(GetUserId(), col_privileges,
+ select_best_grantor(istmt->grantor, col_privileges,
merged_acl, ownerId,
&grantorId, &avail_goptions);
@@ -1969,7 +1958,7 @@ ExecGrant_Relation(InternalGrant *istmt)
ObjectType objtype;
/* Determine ID to do the grant as, and available grant options */
- select_best_grantor(GetUserId(), this_privileges,
+ select_best_grantor(istmt->grantor, this_privileges,
old_acl, ownerId,
&grantorId, &avail_goptions);
@@ -2184,7 +2173,7 @@ ExecGrant_common(InternalGrant *istmt, Oid classid, AclMode default_privs,
}
/* Determine ID to do the grant as, and available grant options */
- select_best_grantor(GetUserId(), istmt->privileges,
+ select_best_grantor(istmt->grantor, istmt->privileges,
old_acl, ownerId,
&grantorId, &avail_goptions);
@@ -2339,7 +2328,7 @@ ExecGrant_Largeobject(InternalGrant *istmt)
}
/* Determine ID to do the grant as, and available grant options */
- select_best_grantor(GetUserId(), istmt->privileges,
+ select_best_grantor(istmt->grantor, istmt->privileges,
old_acl, ownerId,
&grantorId, &avail_goptions);
@@ -2485,7 +2474,7 @@ ExecGrant_Parameter(InternalGrant *istmt)
}
/* Determine ID to do the grant as, and available grant options */
- select_best_grantor(GetUserId(), istmt->privileges,
+ select_best_grantor(istmt->grantor, istmt->privileges,
old_acl, ownerId,
&grantorId, &avail_goptions);
diff --git a/src/backend/utils/adt/acl.c b/src/backend/utils/adt/acl.c
index 3a6905f9546..90fa49eacb7 100644
--- a/src/backend/utils/adt/acl.c
+++ b/src/backend/utils/adt/acl.c
@@ -5451,6 +5451,10 @@ select_best_admin(Oid member, Oid role)
/*
* Select the effective grantor ID for a GRANT or REVOKE operation.
*
+ * If the GRANT/REVOKE has an explicit GRANTED BY clause, we always use
+ * exactly that role (which may result in granting/revoking no privileges).
+ * Otherwise, we seek a "best" grantor, starting with the current user.
+ *
* The grantor must always be either the object owner or some role that has
* been explicitly granted grant options. This ensures that all granted
* privileges appear to flow from the object owner, and there are never
@@ -5463,25 +5467,44 @@ select_best_admin(Oid member, Oid role)
* role has 'em all. In this case we pick a role with the largest number
* of desired options. Ties are broken in favor of closer ancestors.
*
- * roleId: the role attempting to do the GRANT/REVOKE
+ * grantedBy: the GRANTED BY clause of GRANT/REVOKE, or NULL if none
* privileges: the privileges to be granted/revoked
* acl: the ACL of the object in question
* ownerId: the role owning the object in question
* *grantorId: receives the OID of the role to do the grant as
- * *grantOptions: receives the grant options actually held by grantorId
- *
- * If no grant options exist, we set grantorId to roleId, grantOptions to 0.
+ * *grantOptions: receives grant options actually held by grantorId (maybe 0)
*/
void
-select_best_grantor(Oid roleId, AclMode privileges,
+select_best_grantor(const RoleSpec *grantedBy, AclMode privileges,
const Acl *acl, Oid ownerId,
Oid *grantorId, AclMode *grantOptions)
{
+ Oid roleId = GetUserId();
AclMode needed_goptions = ACL_GRANT_OPTION_FOR(privileges);
List *roles_list;
int nrights;
ListCell *l;
+ /*
+ * If we have GRANTED BY, resolve it and verify current user is allowed to
+ * specify that role.
+ */
+ if (grantedBy)
+ {
+ Oid grantor = get_rolespec_oid(grantedBy, false);
+
+ if (!has_privs_of_role(roleId, grantor))
+ ereport(ERROR,
+ (errcode(ERRCODE_INSUFFICIENT_PRIVILEGE),
+ errmsg("must inherit privileges of role \"%s\"",
+ GetUserNameFromId(grantor, false))));
+ /* Use exactly that grantor, whether it has privileges or not */
+ *grantorId = grantor;
+ *grantOptions = aclmask_direct(acl, grantor, ownerId,
+ needed_goptions, ACLMASK_ALL);
+ return;
+ }
+
/*
* The object owner is always treated as having all grant options, so if
* roleId is the owner it's easy. Also, if roleId is a superuser it's
diff --git a/src/include/nodes/parsenodes.h b/src/include/nodes/parsenodes.h
index 646d6ced763..b12f21d22e9 100644
--- a/src/include/nodes/parsenodes.h
+++ b/src/include/nodes/parsenodes.h
@@ -2613,7 +2613,7 @@ typedef struct GrantStmt
/* privileges == NIL denotes ALL PRIVILEGES */
List *grantees; /* list of RoleSpec nodes */
bool grant_option; /* grant or revoke grant option */
- RoleSpec *grantor;
+ RoleSpec *grantor; /* GRANTED BY clause, or NULL if none */
DropBehavior behavior; /* drop behavior (for REVOKE) */
} GrantStmt;
diff --git a/src/include/utils/acl.h b/src/include/utils/acl.h
index ec01fd581cf..9da62a7aa76 100644
--- a/src/include/utils/acl.h
+++ b/src/include/utils/acl.h
@@ -223,7 +223,7 @@ extern void check_rolespec_name(const RoleSpec *role, const char *detail_msg);
extern HeapTuple get_rolespec_tuple(const RoleSpec *role);
extern char *get_rolespec_name(const RoleSpec *role);
-extern void select_best_grantor(Oid roleId, AclMode privileges,
+extern void select_best_grantor(const RoleSpec *grantedBy, AclMode privileges,
const Acl *acl, Oid ownerId,
Oid *grantorId, AclMode *grantOptions);
diff --git a/src/include/utils/aclchk_internal.h b/src/include/utils/aclchk_internal.h
index 38317e2ed37..fa0b65fbba7 100644
--- a/src/include/utils/aclchk_internal.h
+++ b/src/include/utils/aclchk_internal.h
@@ -38,6 +38,7 @@ typedef struct
List *col_privs;
List *grantees;
bool grant_option;
+ RoleSpec *grantor;
DropBehavior behavior;
} InternalGrant;
diff --git a/src/test/regress/expected/privileges.out b/src/test/regress/expected/privileges.out
index daafaa94fde..997c4b68f47 100644
--- a/src/test/regress/expected/privileges.out
+++ b/src/test/regress/expected/privileges.out
@@ -321,7 +321,7 @@ SELECT pg_get_acl(0, 0, 0); -- null
(1 row)
GRANT TRUNCATE ON atest2 TO regress_priv_user4 GRANTED BY regress_priv_user5; -- error
-ERROR: grantor must be current user
+ERROR: must inherit privileges of role "regress_priv_user5"
SET SESSION AUTHORIZATION regress_priv_user2;
SELECT session_user, current_user;
session_user | current_user
^ permalink raw reply [nested|flat] 18+ messages in thread
* Re: Revoke Connect Privilege from Database not working
2025-04-07 13:42 Re: Re: Revoke Connect Privilege from Database not working David G. Johnston <david.g.johnston@gmail.com>
2025-04-07 14:27 ` Aw: Re: Re: Revoke Connect Privilege from Database not working Ing. Marijo Kristo <marijo.kristo@icloud.com>
2025-04-07 15:37 ` Re: Re: Re: Revoke Connect Privilege from Database not working David G. Johnston <david.g.johnston@gmail.com>
2025-04-07 16:06 ` Re: Re: Re: Revoke Connect Privilege from Database not working Tom Lane <tgl@sss.pgh.pa.us>
2025-04-07 16:22 ` Re: Re: Re: Revoke Connect Privilege from Database not working David G. Johnston <david.g.johnston@gmail.com>
2025-11-13 16:47 ` Re: Re: Re: Revoke Connect Privilege from Database not working Nathan Bossart <nathandbossart@gmail.com>
2026-01-20 23:05 ` Re: Revoke Connect Privilege from Database not working Tom Lane <tgl@sss.pgh.pa.us>
@ 2026-01-21 15:28 ` Nathan Bossart <nathandbossart@gmail.com>
2026-01-21 16:57 ` Re: Revoke Connect Privilege from Database not working Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 1 reply; 18+ messages in thread
From: Nathan Bossart @ 2026-01-21 15:28 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: David G. Johnston <david.g.johnston@gmail.com>; Ing. Marijo Kristo <marijo.kristo@icloud.com>; PostgreSQL Bug List <pgsql-bugs@lists.postgresql.org>
On Tue, Jan 20, 2026 at 06:05:41PM -0500, Tom Lane wrote:
> Motivated by the discussion at [1], I'd started on the same idea,
> but arrived at a rather different refactorization. I think this
> way is nicer (less duplicated logic). Either way, we need to
> address the docs and probably add more regression tests.
Yeah, I think doing most of the work in select_best_grantor() is obviously
better. I recall wondering whether we should check for INHERIT or SET
privilege (or both) on the grantor role, and IIRC I settled on INHERIT
because select_best_grantor() searches through roles we have INHERIT on.
Would you like to handle docs/tests/committing, or shall I?
--
nathan
^ permalink raw reply [nested|flat] 18+ messages in thread
* Re: Revoke Connect Privilege from Database not working
2025-04-07 13:42 Re: Re: Revoke Connect Privilege from Database not working David G. Johnston <david.g.johnston@gmail.com>
2025-04-07 14:27 ` Aw: Re: Re: Revoke Connect Privilege from Database not working Ing. Marijo Kristo <marijo.kristo@icloud.com>
2025-04-07 15:37 ` Re: Re: Re: Revoke Connect Privilege from Database not working David G. Johnston <david.g.johnston@gmail.com>
2025-04-07 16:06 ` Re: Re: Re: Revoke Connect Privilege from Database not working Tom Lane <tgl@sss.pgh.pa.us>
2025-04-07 16:22 ` Re: Re: Re: Revoke Connect Privilege from Database not working David G. Johnston <david.g.johnston@gmail.com>
2025-11-13 16:47 ` Re: Re: Re: Revoke Connect Privilege from Database not working Nathan Bossart <nathandbossart@gmail.com>
2026-01-20 23:05 ` Re: Revoke Connect Privilege from Database not working Tom Lane <tgl@sss.pgh.pa.us>
2026-01-21 15:28 ` Re: Revoke Connect Privilege from Database not working Nathan Bossart <nathandbossart@gmail.com>
@ 2026-01-21 16:57 ` Tom Lane <tgl@sss.pgh.pa.us>
2026-03-06 22:01 ` Re: Revoke Connect Privilege from Database not working Nathan Bossart <nathandbossart@gmail.com>
0 siblings, 1 reply; 18+ messages in thread
From: Tom Lane @ 2026-01-21 16:57 UTC (permalink / raw)
To: Nathan Bossart <nathandbossart@gmail.com>; +Cc: Robert Haas <robertmhaas@gmail.com>; Peter Eisentraut <peter@eisentraut.org>; David G. Johnston <david.g.johnston@gmail.com>; Ing. Marijo Kristo <marijo.kristo@icloud.com>; PostgreSQL Bug List <pgsql-bugs@lists.postgresql.org>
Nathan Bossart <nathandbossart@gmail.com> writes:
> Yeah, I think doing most of the work in select_best_grantor() is obviously
> better. I recall wondering whether we should check for INHERIT or SET
> privilege (or both) on the grantor role, and IIRC I settled on INHERIT
> because select_best_grantor() searches through roles we have INHERIT on.
Yeah, I mentally had that point as something to check on. Clearly,
if you have SET ROLE privilege then you can become the target role
and then issue the GRANT, so if we define GRANTED BY like that
then we're not allowing anything that can't be done today. However,
it feels like INHERIT is a more natural test to make, since AIUI
that is what permits "automatic" use of a role's privileges, and that
seems to be what we'd be doing here.
I'd be interested to hear Robert's opinion on this, or somebody
else who worked on the SET/INHERIT splitup.
Also cc'ing Peter, who put in the current effectively-a-noise-clause
behavior of GRANTED BY, to see if he has standards-compliance or
other concerns about changing this.
> Would you like to handle docs/tests/committing, or shall I?
I'm willing to push it forward if we have consensus to do it.
regards, tom lane
^ permalink raw reply [nested|flat] 18+ messages in thread
* Re: Revoke Connect Privilege from Database not working
2025-04-07 13:42 Re: Re: Revoke Connect Privilege from Database not working David G. Johnston <david.g.johnston@gmail.com>
2025-04-07 14:27 ` Aw: Re: Re: Revoke Connect Privilege from Database not working Ing. Marijo Kristo <marijo.kristo@icloud.com>
2025-04-07 15:37 ` Re: Re: Re: Revoke Connect Privilege from Database not working David G. Johnston <david.g.johnston@gmail.com>
2025-04-07 16:06 ` Re: Re: Re: Revoke Connect Privilege from Database not working Tom Lane <tgl@sss.pgh.pa.us>
2025-04-07 16:22 ` Re: Re: Re: Revoke Connect Privilege from Database not working David G. Johnston <david.g.johnston@gmail.com>
2025-11-13 16:47 ` Re: Re: Re: Revoke Connect Privilege from Database not working Nathan Bossart <nathandbossart@gmail.com>
2026-01-20 23:05 ` Re: Revoke Connect Privilege from Database not working Tom Lane <tgl@sss.pgh.pa.us>
2026-01-21 15:28 ` Re: Revoke Connect Privilege from Database not working Nathan Bossart <nathandbossart@gmail.com>
2026-01-21 16:57 ` Re: Revoke Connect Privilege from Database not working Tom Lane <tgl@sss.pgh.pa.us>
@ 2026-03-06 22:01 ` Nathan Bossart <nathandbossart@gmail.com>
2026-03-18 00:50 ` Re: Revoke Connect Privilege from Database not working Nathan Bossart <nathandbossart@gmail.com>
0 siblings, 1 reply; 18+ messages in thread
From: Nathan Bossart @ 2026-03-06 22:01 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: Robert Haas <robertmhaas@gmail.com>; Peter Eisentraut <peter@eisentraut.org>; David G. Johnston <david.g.johnston@gmail.com>; Ing. Marijo Kristo <marijo.kristo@icloud.com>; PostgreSQL Bug List <pgsql-bugs@lists.postgresql.org>
On Wed, Jan 21, 2026 at 11:57:01AM -0500, Tom Lane wrote:
> Nathan Bossart <nathandbossart@gmail.com> writes:
>> Yeah, I think doing most of the work in select_best_grantor() is obviously
>> better. I recall wondering whether we should check for INHERIT or SET
>> privilege (or both) on the grantor role, and IIRC I settled on INHERIT
>> because select_best_grantor() searches through roles we have INHERIT on.
>
> Yeah, I mentally had that point as something to check on. Clearly,
> if you have SET ROLE privilege then you can become the target role
> and then issue the GRANT, so if we define GRANTED BY like that
> then we're not allowing anything that can't be done today. However,
> it feels like INHERIT is a more natural test to make, since AIUI
> that is what permits "automatic" use of a role's privileges, and that
> seems to be what we'd be doing here.
Agreed.
> I'd be interested to hear Robert's opinion on this, or somebody
> else who worked on the SET/INHERIT splitup.
>
> Also cc'ing Peter, who put in the current effectively-a-noise-clause
> behavior of GRANTED BY, to see if he has standards-compliance or
> other concerns about changing this.
Robert/Peter, do you have any thoughts about expanding GRANT/REVOKE GRANTED
BY like this? I think it would've helped with a couple of reports received
during this development cycle, and IMHO it'd be a nice little feature for
v19.
--
nathan
^ permalink raw reply [nested|flat] 18+ messages in thread
* Re: Revoke Connect Privilege from Database not working
2025-04-07 13:42 Re: Re: Revoke Connect Privilege from Database not working David G. Johnston <david.g.johnston@gmail.com>
2025-04-07 14:27 ` Aw: Re: Re: Revoke Connect Privilege from Database not working Ing. Marijo Kristo <marijo.kristo@icloud.com>
2025-04-07 15:37 ` Re: Re: Re: Revoke Connect Privilege from Database not working David G. Johnston <david.g.johnston@gmail.com>
2025-04-07 16:06 ` Re: Re: Re: Revoke Connect Privilege from Database not working Tom Lane <tgl@sss.pgh.pa.us>
2025-04-07 16:22 ` Re: Re: Re: Revoke Connect Privilege from Database not working David G. Johnston <david.g.johnston@gmail.com>
2025-11-13 16:47 ` Re: Re: Re: Revoke Connect Privilege from Database not working Nathan Bossart <nathandbossart@gmail.com>
2026-01-20 23:05 ` Re: Revoke Connect Privilege from Database not working Tom Lane <tgl@sss.pgh.pa.us>
2026-01-21 15:28 ` Re: Revoke Connect Privilege from Database not working Nathan Bossart <nathandbossart@gmail.com>
2026-01-21 16:57 ` Re: Revoke Connect Privilege from Database not working Tom Lane <tgl@sss.pgh.pa.us>
2026-03-06 22:01 ` Re: Revoke Connect Privilege from Database not working Nathan Bossart <nathandbossart@gmail.com>
@ 2026-03-18 00:50 ` Nathan Bossart <nathandbossart@gmail.com>
2026-03-18 16:36 ` Re: Revoke Connect Privilege from Database not working Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 1 reply; 18+ messages in thread
From: Nathan Bossart @ 2026-03-18 00:50 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: Robert Haas <robertmhaas@gmail.com>; Peter Eisentraut <peter@eisentraut.org>; David G. Johnston <david.g.johnston@gmail.com>; Ing. Marijo Kristo <marijo.kristo@icloud.com>; PostgreSQL Bug List <pgsql-bugs@lists.postgresql.org>
I went ahead and tried adding docs, tests, and a commit message. The
documentation for these commands might need a revamp. They seem to meander
a bit, probably due to decades of organic development. But that's probably
not this patch's problem.
--
nathan
^ permalink raw reply [nested|flat] 18+ messages in thread
* Re: Revoke Connect Privilege from Database not working
2025-04-07 13:42 Re: Re: Revoke Connect Privilege from Database not working David G. Johnston <david.g.johnston@gmail.com>
2025-04-07 14:27 ` Aw: Re: Re: Revoke Connect Privilege from Database not working Ing. Marijo Kristo <marijo.kristo@icloud.com>
2025-04-07 15:37 ` Re: Re: Re: Revoke Connect Privilege from Database not working David G. Johnston <david.g.johnston@gmail.com>
2025-04-07 16:06 ` Re: Re: Re: Revoke Connect Privilege from Database not working Tom Lane <tgl@sss.pgh.pa.us>
2025-04-07 16:22 ` Re: Re: Re: Revoke Connect Privilege from Database not working David G. Johnston <david.g.johnston@gmail.com>
2025-11-13 16:47 ` Re: Re: Re: Revoke Connect Privilege from Database not working Nathan Bossart <nathandbossart@gmail.com>
2026-01-20 23:05 ` Re: Revoke Connect Privilege from Database not working Tom Lane <tgl@sss.pgh.pa.us>
2026-01-21 15:28 ` Re: Revoke Connect Privilege from Database not working Nathan Bossart <nathandbossart@gmail.com>
2026-01-21 16:57 ` Re: Revoke Connect Privilege from Database not working Tom Lane <tgl@sss.pgh.pa.us>
2026-03-06 22:01 ` Re: Revoke Connect Privilege from Database not working Nathan Bossart <nathandbossart@gmail.com>
2026-03-18 00:50 ` Re: Revoke Connect Privilege from Database not working Nathan Bossart <nathandbossart@gmail.com>
@ 2026-03-18 16:36 ` Tom Lane <tgl@sss.pgh.pa.us>
2026-03-18 17:47 ` Re: Revoke Connect Privilege from Database not working Nathan Bossart <nathandbossart@gmail.com>
0 siblings, 1 reply; 18+ messages in thread
From: Tom Lane @ 2026-03-18 16:36 UTC (permalink / raw)
To: Nathan Bossart <nathandbossart@gmail.com>; +Cc: Robert Haas <robertmhaas@gmail.com>; Peter Eisentraut <peter@eisentraut.org>; David G. Johnston <david.g.johnston@gmail.com>; Ing. Marijo Kristo <marijo.kristo@icloud.com>; PostgreSQL Bug List <pgsql-bugs@lists.postgresql.org>
Nathan Bossart <nathandbossart@gmail.com> writes:
> I went ahead and tried adding docs, tests, and a commit message.
Thanks! I was about to conclude that "silence means assent" and
do that work, but you beat me to it. Your changes look fine,
except that where you have
+ ... A role can only attribute a grant
+ to another role if they possess the privileges of that role.
the word "possess" seems a little ambiguous --- it's not clear whether
it means SET or INHERIT privileges. The grammar nerd in me doesn't
like "they" either. How about s/they possess/it inherits/ ?
(likewise in revoke.sgml)
> The
> documentation for these commands might need a revamp. They seem to meander
> a bit, probably due to decades of organic development. But that's probably
> not this patch's problem.
Agreed, seems like a task for another day.
regards, tom lane
^ permalink raw reply [nested|flat] 18+ messages in thread
* Re: Revoke Connect Privilege from Database not working
2025-04-07 13:42 Re: Re: Revoke Connect Privilege from Database not working David G. Johnston <david.g.johnston@gmail.com>
2025-04-07 14:27 ` Aw: Re: Re: Revoke Connect Privilege from Database not working Ing. Marijo Kristo <marijo.kristo@icloud.com>
2025-04-07 15:37 ` Re: Re: Re: Revoke Connect Privilege from Database not working David G. Johnston <david.g.johnston@gmail.com>
2025-04-07 16:06 ` Re: Re: Re: Revoke Connect Privilege from Database not working Tom Lane <tgl@sss.pgh.pa.us>
2025-04-07 16:22 ` Re: Re: Re: Revoke Connect Privilege from Database not working David G. Johnston <david.g.johnston@gmail.com>
2025-11-13 16:47 ` Re: Re: Re: Revoke Connect Privilege from Database not working Nathan Bossart <nathandbossart@gmail.com>
2026-01-20 23:05 ` Re: Revoke Connect Privilege from Database not working Tom Lane <tgl@sss.pgh.pa.us>
2026-01-21 15:28 ` Re: Revoke Connect Privilege from Database not working Nathan Bossart <nathandbossart@gmail.com>
2026-01-21 16:57 ` Re: Revoke Connect Privilege from Database not working Tom Lane <tgl@sss.pgh.pa.us>
2026-03-06 22:01 ` Re: Revoke Connect Privilege from Database not working Nathan Bossart <nathandbossart@gmail.com>
2026-03-18 00:50 ` Re: Revoke Connect Privilege from Database not working Nathan Bossart <nathandbossart@gmail.com>
2026-03-18 16:36 ` Re: Revoke Connect Privilege from Database not working Tom Lane <tgl@sss.pgh.pa.us>
@ 2026-03-18 17:47 ` Nathan Bossart <nathandbossart@gmail.com>
2026-03-18 17:58 ` Re: Revoke Connect Privilege from Database not working Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 1 reply; 18+ messages in thread
From: Nathan Bossart @ 2026-03-18 17:47 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: Robert Haas <robertmhaas@gmail.com>; Peter Eisentraut <peter@eisentraut.org>; David G. Johnston <david.g.johnston@gmail.com>; Ing. Marijo Kristo <marijo.kristo@icloud.com>; PostgreSQL Bug List <pgsql-bugs@lists.postgresql.org>
On Wed, Mar 18, 2026 at 12:36:17PM -0400, Tom Lane wrote:
> Thanks! I was about to conclude that "silence means assent" and
> do that work, but you beat me to it. Your changes look fine,
> except that where you have
Thanks for reviewing.
> + ... A role can only attribute a grant
> + to another role if they possess the privileges of that role.
>
> the word "possess" seems a little ambiguous --- it's not clear whether
> it means SET or INHERIT privileges. The grammar nerd in me doesn't
> like "they" either. How about s/they possess/it inherits/ ?
> (likewise in revoke.sgml)
This crossed my mind when copy/pasting from the "GRANT on Roles" section,
but I obviously didn't do anything about it. Fixed in the attached.
--
nathan
^ permalink raw reply [nested|flat] 18+ messages in thread
* Re: Revoke Connect Privilege from Database not working
2025-04-07 13:42 Re: Re: Revoke Connect Privilege from Database not working David G. Johnston <david.g.johnston@gmail.com>
2025-04-07 14:27 ` Aw: Re: Re: Revoke Connect Privilege from Database not working Ing. Marijo Kristo <marijo.kristo@icloud.com>
2025-04-07 15:37 ` Re: Re: Re: Revoke Connect Privilege from Database not working David G. Johnston <david.g.johnston@gmail.com>
2025-04-07 16:06 ` Re: Re: Re: Revoke Connect Privilege from Database not working Tom Lane <tgl@sss.pgh.pa.us>
2025-04-07 16:22 ` Re: Re: Re: Revoke Connect Privilege from Database not working David G. Johnston <david.g.johnston@gmail.com>
2025-11-13 16:47 ` Re: Re: Re: Revoke Connect Privilege from Database not working Nathan Bossart <nathandbossart@gmail.com>
2026-01-20 23:05 ` Re: Revoke Connect Privilege from Database not working Tom Lane <tgl@sss.pgh.pa.us>
2026-01-21 15:28 ` Re: Revoke Connect Privilege from Database not working Nathan Bossart <nathandbossart@gmail.com>
2026-01-21 16:57 ` Re: Revoke Connect Privilege from Database not working Tom Lane <tgl@sss.pgh.pa.us>
2026-03-06 22:01 ` Re: Revoke Connect Privilege from Database not working Nathan Bossart <nathandbossart@gmail.com>
2026-03-18 00:50 ` Re: Revoke Connect Privilege from Database not working Nathan Bossart <nathandbossart@gmail.com>
2026-03-18 16:36 ` Re: Revoke Connect Privilege from Database not working Tom Lane <tgl@sss.pgh.pa.us>
2026-03-18 17:47 ` Re: Revoke Connect Privilege from Database not working Nathan Bossart <nathandbossart@gmail.com>
@ 2026-03-18 17:58 ` Tom Lane <tgl@sss.pgh.pa.us>
2026-03-19 16:44 ` Re: Revoke Connect Privilege from Database not working Nathan Bossart <nathandbossart@gmail.com>
0 siblings, 1 reply; 18+ messages in thread
From: Tom Lane @ 2026-03-18 17:58 UTC (permalink / raw)
To: Nathan Bossart <nathandbossart@gmail.com>; +Cc: Robert Haas <robertmhaas@gmail.com>; Peter Eisentraut <peter@eisentraut.org>; David G. Johnston <david.g.johnston@gmail.com>; Ing. Marijo Kristo <marijo.kristo@icloud.com>; PostgreSQL Bug List <pgsql-bugs@lists.postgresql.org>
Nathan Bossart <nathandbossart@gmail.com> writes:
> On Wed, Mar 18, 2026 at 12:36:17PM -0400, Tom Lane wrote:
>> the word "possess" seems a little ambiguous --- it's not clear whether
>> it means SET or INHERIT privileges. The grammar nerd in me doesn't
>> like "they" either. How about s/they possess/it inherits/ ?
>> (likewise in revoke.sgml)
> This crossed my mind when copy/pasting from the "GRANT on Roles" section,
> but I obviously didn't do anything about it. Fixed in the attached.
v4 LGTM.
regards, tom lane
^ permalink raw reply [nested|flat] 18+ messages in thread
* Re: Revoke Connect Privilege from Database not working
2025-04-07 13:42 Re: Re: Revoke Connect Privilege from Database not working David G. Johnston <david.g.johnston@gmail.com>
2025-04-07 14:27 ` Aw: Re: Re: Revoke Connect Privilege from Database not working Ing. Marijo Kristo <marijo.kristo@icloud.com>
2025-04-07 15:37 ` Re: Re: Re: Revoke Connect Privilege from Database not working David G. Johnston <david.g.johnston@gmail.com>
2025-04-07 16:06 ` Re: Re: Re: Revoke Connect Privilege from Database not working Tom Lane <tgl@sss.pgh.pa.us>
2025-04-07 16:22 ` Re: Re: Re: Revoke Connect Privilege from Database not working David G. Johnston <david.g.johnston@gmail.com>
2025-11-13 16:47 ` Re: Re: Re: Revoke Connect Privilege from Database not working Nathan Bossart <nathandbossart@gmail.com>
2026-01-20 23:05 ` Re: Revoke Connect Privilege from Database not working Tom Lane <tgl@sss.pgh.pa.us>
2026-01-21 15:28 ` Re: Revoke Connect Privilege from Database not working Nathan Bossart <nathandbossart@gmail.com>
2026-01-21 16:57 ` Re: Revoke Connect Privilege from Database not working Tom Lane <tgl@sss.pgh.pa.us>
2026-03-06 22:01 ` Re: Revoke Connect Privilege from Database not working Nathan Bossart <nathandbossart@gmail.com>
2026-03-18 00:50 ` Re: Revoke Connect Privilege from Database not working Nathan Bossart <nathandbossart@gmail.com>
2026-03-18 16:36 ` Re: Revoke Connect Privilege from Database not working Tom Lane <tgl@sss.pgh.pa.us>
2026-03-18 17:47 ` Re: Revoke Connect Privilege from Database not working Nathan Bossart <nathandbossart@gmail.com>
2026-03-18 17:58 ` Re: Revoke Connect Privilege from Database not working Tom Lane <tgl@sss.pgh.pa.us>
@ 2026-03-19 16:44 ` Nathan Bossart <nathandbossart@gmail.com>
0 siblings, 0 replies; 18+ messages in thread
From: Nathan Bossart @ 2026-03-19 16:44 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: Robert Haas <robertmhaas@gmail.com>; Peter Eisentraut <peter@eisentraut.org>; David G. Johnston <david.g.johnston@gmail.com>; Ing. Marijo Kristo <marijo.kristo@icloud.com>; PostgreSQL Bug List <pgsql-bugs@lists.postgresql.org>
On Wed, Mar 18, 2026 at 01:58:55PM -0400, Tom Lane wrote:
> v4 LGTM.
Thanks, committed.
--
nathan
^ permalink raw reply [nested|flat] 18+ messages in thread
end of thread, other threads:[~2026-03-19 16:44 UTC | newest]
Thread overview: 18+ messages (download: mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2025-03-31 15:26 Revoke Connect Privilege from Database not working Ing. Marijo Kristo <marijo.kristo@icloud.com>
2025-04-01 14:13 ` Tom Lane <tgl@sss.pgh.pa.us>
2025-04-01 14:15 ` David G. Johnston <david.g.johnston@gmail.com>
2025-04-07 13:42 Re: Re: Revoke Connect Privilege from Database not working David G. Johnston <david.g.johnston@gmail.com>
2025-04-07 14:27 ` Aw: Re: Re: Revoke Connect Privilege from Database not working Ing. Marijo Kristo <marijo.kristo@icloud.com>
2025-04-07 15:37 ` David G. Johnston <david.g.johnston@gmail.com>
2025-04-07 16:06 ` Tom Lane <tgl@sss.pgh.pa.us>
2025-04-07 16:22 ` David G. Johnston <david.g.johnston@gmail.com>
2025-11-13 16:47 ` Nathan Bossart <nathandbossart@gmail.com>
2026-01-20 23:05 ` Tom Lane <tgl@sss.pgh.pa.us>
2026-01-21 15:28 ` Nathan Bossart <nathandbossart@gmail.com>
2026-01-21 16:57 ` Tom Lane <tgl@sss.pgh.pa.us>
2026-03-06 22:01 ` Nathan Bossart <nathandbossart@gmail.com>
2026-03-18 00:50 ` Nathan Bossart <nathandbossart@gmail.com>
2026-03-18 16:36 ` Tom Lane <tgl@sss.pgh.pa.us>
2026-03-18 17:47 ` Nathan Bossart <nathandbossart@gmail.com>
2026-03-18 17:58 ` Tom Lane <tgl@sss.pgh.pa.us>
2026-03-19 16:44 ` Nathan Bossart <nathandbossart@gmail.com>
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox