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

Re: Re: BUG #6264: Superuser does not have inherent Replication permission

From: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
To: Noah Misch <noah(at)leadboat(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-14 16:34:25
Message-ID: 4F11AE91.4020407@enterprisedb.com (view raw or flat)
Thread:
Lists: pgsql-bugs
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.

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.

-- 
   Heikki Linnakangas
   EnterpriseDB   http://www.enterprisedb.com

In response to

Responses

pgsql-bugs by date

Next:From: Noah MischDate: 2012-01-15 00:27:34
Subject: Re: Re: BUG #6264: Superuser does not have inherentReplication permission
Previous:From: John R PierceDate: 2012-01-13 19:48:08
Subject: Re: BUG #6397: I am getting error on CIFS with fsync parameter on

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