| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Konstantin Knizhnik <knizhnik(at)garret(dot)ru> |
| Cc: | Nathan Bossart <nathandbossart(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Peter Eisentraut <peter(at)eisentraut(dot)org> |
| Subject: | Re: Mystery with REVOKE PRIVILEGE |
| Date: | 2026-01-22 16:35:16 |
| Message-ID: | 2716313.1769099716@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Konstantin Knizhnik <knizhnik(at)garret(dot)ru> writes:
> But I wonder if we do refactoring of this revoke privileges stuff,
> should we also provide correct (expected) behaviour in case of missing
> grantor specification. i.e.
> revoke all privileges on table <T> from <role>;
> If privileges to access this table were granted to this role by multiple
> grantors, then it is natural to expect that the statement above will
> remove all such grants and so as a result <role> can not access this
> table any more, rather than try to find best grantor and finally still
> leave privileges for this role, isn't it?
Unfortunately, the SQL spec is quite clear that REVOKE revokes only
privileges granted directly by the calling user (or the GRANTED BY
role, if that's given). We're already far outside the spec by
allowing select_best_grantor to locate an inherited role to do the
revoke as. I can't see reinterpreting it as "revoke all privileges
granted by anybody", even assuming that the calling user has
sufficient permissions to do that.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Anthonin Bonnefoy | 2026-01-22 16:42:44 | Fix rounding method used to compute huge pages |
| Previous Message | Srirama Kucherlapati | 2026-01-22 16:08:36 | RE: AIX support |