Re: Streaming replication as a separate permissions
От | Magnus Hagander |
---|---|
Тема | Re: Streaming replication as a separate permissions |
Дата | |
Msg-id | AANLkTimj0b--wyMX4x6UhRTOc39mOZEXZgbFdiF+1nNa@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Streaming replication as a separate permissions (Stephen Frost <sfrost@snowman.net>) |
Ответы |
Re: Streaming replication as a separate permissions
|
Список | pgsql-hackers |
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/
В списке pgsql-hackers по дате отправления: