Skip site navigation (1) Skip section navigation (2)

Re: Re: BUG #6264: Superuser does not have inherentReplication permission

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 inherentReplication permission
Date: 2012-01-15 00:27:34
Message-ID: 20120115002734.GA21684@tornado.leadboat.com (view raw or flat)
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.

In response to

pgsql-bugs by date

Next:From: yamtDate: 2012-01-16 09:32:24
Subject: BUG #6399: knngist sometimes returns tuples in incorrect order
Previous:From: Heikki LinnakangasDate: 2012-01-14 16:34:25
Subject: Re: Re: BUG #6264: Superuser does not have inherent Replication permission

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group