Re: Streaming replication as a separate permissions

On Fri, Dec 24, 2010 at 05:46, Stephen Frost <sfrost(at)snowman(dot)net> wrote:
> * Robert Haas (robertmhaas(at)gmail(dot)com) wrote:
>> I think I agree with Florian about the confusing-ness of the proposed
>> semantics.  Aren't you saying you want NOLOGIN mean "not allowed to
>> log in for the purposes of issuing SQL commands, but allowed to log in
>> for replication"?  Uggh.
>
> I like the general idea of a replication-only "role" or "login".  Maybe
> implementing that as a role w/ all the things that come along with it
> being a role isn't right, but we don't want to have to reinvent all the
> supported auth mechanisms (and please don't propose limiting the auth
> options for the replication login!).  Is there a way we can leverage the
> auth mechanisms, etc, while forcing the 'replication role' to only be
> able to do what a 'replication role' should do?

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. Though we could perhaps restrict that as well in the SET
ROLE processing code).

This requires there to be a separate user for replication in all cases
- which isn't a bad thing IMHO. And it also doesn't "abuse"/confuse
the NOLOGIN attribute.

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