On Fri, Dec 24, 2010 at 05:46, Stephen Frost <sfr...@snowman.net> wrote: > * Robert Haas (robertmh...@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/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
