On Fri, Dec 24, 2010 at 05:46, Stephen Frost <sfrost@snowman.net> wrote:
> * Robert Haas (robertmhaas@gmail.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/
