Re: Re: BUG #6264: Superuser does not have inherent Replication permission
От | Noah Misch |
---|---|
Тема | Re: Re: BUG #6264: Superuser does not have inherent Replication permission |
Дата | |
Msg-id | 20120115002734.GA21684@tornado.leadboat.com обсуждение исходный текст |
Ответ на | Re: Re: BUG #6264: Superuser does not have inherent Replication permission (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>) |
Список | pgsql-bugs |
On Sat, Jan 14, 2012 at 06:34:25PM +0200, Heikki Linnakangas wrote: > On 02.01.2012 21:46, Noah Misch wrote: >> On Fri, Oct 28, 2011 at 11:42:38AM -0400, Noah Misch wrote: >>> On Fri, Oct 28, 2011 at 09:32:30AM -0400, Robert Haas wrote: >>>> On Thu, Oct 27, 2011 at 6:15 PM, Tom Lane<tgl@sss.pgh.pa.us> wrote: >>>>> Noah Misch<noah@leadboat.com> writes: >>>>>> Let's look at the behavior of DDL-exposed access constraints for precedent. ?We >>>>>> currently have three paradigms for applying access control to superusers: >>>>> >>>>>> 1. Settings that affect superusers and regular users identically. ?These include >>>>>> ALTER ROLE ... LOGIN | VALID UNTIL. >>>>> >>>>>> 2. Rights that superusers possess implicitly and irrevocably; the actual setting >>>>>> recorded in pg_authid or elsewhere has no effect. ?These include GRANT ... ON >>>>>> TABLE and ALTER ROLE ... CREATEDB | CREATEROLE. >>>>> >>>>>> 3. ALTER ROLE ... REPLICATION is very similar to #1, except that CREATE ROLE >>>>>> ... SUPERUSER implies CREATE ROLE ... SUPERUSER REPLICATION. >>>>> >>>>>> I think we should merge #3 into #2; nothing about the REPLICATION setting >>>>>> justifies a distinct paradigm. >>>>> >>>>> Yeah, there's much to be said for that. ?I thought the notion of a >>>>> privilege that superusers might not have was pretty bogus to start with. >>> >>>> That seems fine for 9.2, but I am still not in favor of changing the >>>> behavior in back branches. This is not such a confusing behavior that >>>> we can't document our way out of it. >>>> >>>> (Hey, if SELECT .. ORDER BY .. FOR UPDATE can return rows out of order >>>> and we can document our way out of that, this is small potatoes by >>>> comparison.) >>> >>> Quite so. Let's do it that way. >> >> Patch attached. > > Thanks, committed to master. Thanks. > Was there something that still needed to be done for the 9.1 docs? I'm > not sure what the conclusion on that was in the discussions back in > October. Not that I noted. The former docs describe the 9.1 behavior thoroughly.
В списке pgsql-bugs по дате отправления: