Re: Streaming replication as a separate permissions - Mailing list pgsql-hackers

From Magnus Hagander
Subject Re: Streaming replication as a separate permissions
Date
Msg-id AANLkTimekDJ=68OHBTrGjs8iYXO4gMsmus9ZEAzx3YAE@mail.gmail.com
Whole thread Raw
In response to Re: Streaming replication as a separate permissions  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Streaming replication as a separate permissions
List pgsql-hackers
On Mon, Dec 27, 2010 at 16:33, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Magnus Hagander <magnus@hagander.net> writes:
>> On Mon, Dec 27, 2010 at 10:53, Magnus Hagander <magnus@hagander.net> wrote:
>>> We could quite easily make a replication role *never* be able to
>>> connect to a non-walsender backend. That would mean that if you set
>>> your role to WITH REPLICATION, it can *only* be used for replication
>>> and nothing else (well, you could still SET ROLE to it, but given that
>>> it's not a superuser (anymore), that doesn't have any security
>>> implications.
>
>> Actually, having implemented that and tested it, I realize that's a
>> pretty bad idea.
>
> OK, so if we're not going to recommend that REPLICATION roles be
> NOLOGIN, we're back to the original question: should the REPLICATION
> bit give any other special privileges?  I can see the point of allowing
> such a user to issue pg_start_backup and pg_stop_backup.

Yes, those would definitely be useful.

We are, basically, talking about where we'll relax the "only
superuser" one, right? Since they are normal roles, the DBA can always
GRANT permissions on *objects* to them, but there are superuser-only
things taht you can't GRANT away...


--
 Magnus Hagander
 Me: http://www.hagander.net/
 Work: http://www.redpill-linpro.com/


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Streaming replication as a separate permissions
Next
From: Tom Lane
Date:
Subject: Re: Reduce lock levels for ADD and DROP COLUMN