Re: Safety/validity of resetting permissions by updating system tables

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Andrew Dunstan <andrew(at)dunslane(dot)net>
Cc: Isaac Morland <isaac(dot)morland(at)gmail(dot)com>, PostgreSQL Developers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Safety/validity of resetting permissions by updating system tables
Date: 2021-01-05 16:08:05
Message-ID: 3380406.1609862885@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
> I think there is probably a good case for some sort of "from scratch"
> option on GRANT.

Maybe my head's not screwed on straight this morning, but it seems
to me that any such action would typically be revoking permissions
not adding them, so that it'd be more naturally framed as a REVOKE
option.

There's still the question of exactly what "from scratch" means.
Do we really want it to just reset the acl column to null, forcing
the object to the wired-in defaults? Might be better to reset to
whatever pg_init_privs has, if anything. Also, what about the
effects of any applicable ALTER DEFAULT PRIVILEGES settings?

Maybe we could go with two commands (spelling subject to bikeshedding):

REVOKE ALL NONSTANDARD PRIVILEGES ON object

resets to pg_init_privs state, or null if no entry there

GRANT DEFAULT PRIVILEGES ON object

add any privileges implied by applicable ALTER DEFAULT PRIVILEGES
settings

A different way to look at it, which I think is what the OP had
in mind, is that the existing behaviors are sufficient if you can
say "REVOKE ... FROM ALL". Or, maybe we need that too.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Jim Finnerty 2021-01-05 16:26:50 Re: Challenges preventing us moving to 64 bit transaction id (XID)?
Previous Message Zhihong Yu 2021-01-05 15:51:42 Re: pg_stat_statements and "IN" conditions