From: | Noah Misch <noah(at)leadboat(dot)com> |
---|---|
To: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Magnus Hagander <magnus(at)hagander(dot)net>, Keith Fiske <keith(at)omniti(dot)com>, pgsql-bugs(at)postgresql(dot)org |
Subject: | Re: Re: BUG #6264: Superuser does not have inherent Replication permission |
Date: | 2012-01-15 00:27:34 |
Message-ID: | 20120115002734.GA21684@tornado.leadboat.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>>>> Noah Misch<noah(at)leadboat(dot)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.
From | Date | Subject | |
---|---|---|---|
Next Message | yamt | 2012-01-16 09:32:24 | BUG #6399: knngist sometimes returns tuples in incorrect order |
Previous Message | Heikki Linnakangas | 2012-01-14 16:34:25 | Re: Re: BUG #6264: Superuser does not have inherent Replication permission |