Re: Special role for subscriptions

From: Petr Jelinek <petr(dot)jelinek(at)2ndquadrant(dot)com>
To: Andrey Borodin <x4mmm(at)yandex-team(dot)ru>, Michael Paquier <michael(at)paquier(dot)xyz>
Cc: Euler Taveira <euler(at)timbira(dot)com(dot)br>, Robert Haas <robertmhaas(at)gmail(dot)com>, Evgeniy Efimkin <efimkin(at)yandex-team(dot)ru>, Jeff Davis <pgsql(at)j-davis(dot)com>, Stephen Frost <sfrost(at)snowman(dot)net>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>, Дмитрий Сарафанников <dsarafan(at)yandex-team(dot)ru>, Владимир Бородин <root(at)simply(dot)name>
Subject: Re: Special role for subscriptions
Date: 2019-03-22 11:17:43
Message-ID: f41d93b6-69ba-fa05-c91a-045bafa5f832@2ndquadrant.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

On 22/03/2019 03:15, Andrey Borodin wrote:
>
>> 22 марта 2019 г., в 9:28, Michael Paquier <michael(at)paquier(dot)xyz> написал(а):
>>
>> On Thu, Mar 21, 2019 at 10:06:03AM -0300, Euler Taveira wrote:
>>> It will be really strange but I can live with that. Another idea is
>>> CREATE bit to create subscriptions (without replicate) and SUBSCRIBE
>>> bit to replicate tables. It is not just a privilege to create a
>>> subscription but also to modify tables that a role doesn't have
>>> explicit permission. Let's allocate another AclItem?
>>
>> By the way, as the commit fest is coming to its end in a couple of
>> days, and that we are still discussing how the thing should be shaped,
>> I would recommend to mark the patch as returned with feedback. Any
>> objections with that?
>
> It seems to me that we have consensus that:
> 1. We need special role to create subscription
> 2. This role can create subscription with some security checks
> 3. We have complete list of possible security checks
> 4. We have code that implements most of these checks (I believe pg_subscription_role_v2.patch is enough, but we can tighten checks a little more)
>

I still don't like that we are running the subscription workers as
superuser even for subscriptions created by regular user. That has
plenty of privilege escalation issues in terms of how user functions are
run (we execute triggers, index expressions etc, in that worker).

> Do we have any objection on these points?
>
> If not, it is RFC, it should not be returned.
>

Regardless of my complain above, patch with this big security
implications that has arrived in middle of last CF should not be merged
in that last CF IMHO.

--
Petr Jelinek http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Ramanarayana 2019-03-22 11:29:58 Re: Contribution to Perldoc for TestLib module in Postgres
Previous Message Michael Paquier 2019-03-22 10:39:26 Re: Offline enabling/disabling of data checksums