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
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 |