Re: Special role for subscriptions - Mailing list pgsql-hackers

From Robert Haas
Subject Re: Special role for subscriptions
Date
Msg-id CA+TgmoahEoM2zZO71yv4883HFarXcBcOs3if6fEdRcRs8Fs=zA@mail.gmail.com
Whole thread Raw
In response to Re: Special role for subscriptions  (Michael Paquier <michael@paquier.xyz>)
Responses Re: Special role for subscriptions
Re: Special role for subscriptions
List pgsql-hackers
On Mon, Mar 11, 2019 at 10:39 PM Michael Paquier <michael@paquier.xyz> wrote:
> On Mon, Mar 11, 2019 at 06:32:10PM -0700, Jeff Davis wrote:
> >  * Is the original idea of a special role still viable?
>
> In my opinion, that part may be valuable.  The latest patches proposed
> change the way tables are filtered and listed on the subscription
> side, lowering the permission to spawn a new thread and to connect to a
> publication server by just being a database owner instead of being a
> superuser, and that's quite a gap.

I agree.  I think the original idea was better than what Stephen
suggested, and for basically the reasons you mention.

However, I'm not sure that you are right when you say "just being a
database owner."  I think that what's being proposed is that anybody
who is a *table* owner could make PostgreSQL run off and try to sync
that table from a remote server in perpetuity.  That seems like WAY
too much access to give an unprivileged user.  I don't think we want
unprivileged users to be able to launch more or less permanent
background processes, nor do we want them to be able to initiate
outbound network traffic from the server.  Whether we want database
owners to be able to do those things is more debatable, but even that
would represent a significant expansion of their current rights, IIUC.

Just letting the superuser decide who gets to create subscriptions
seems good enough from here.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: PATCH: Include all columns in default names for foreign keyconstraints.
Next
From: Robert Haas
Date:
Subject: Re: [WIP] CREATE SUBSCRIPTION with FOR TABLES clause (table filter)