Re: logical replication access control patches

On 28/02/17 04:10, Stephen Frost wrote:
> Peter,
>
> * Peter Eisentraut (peter(dot)eisentraut(at)2ndquadrant(dot)com) wrote:
>> On 2/18/17 18:06, Stephen Frost wrote:
>>> I'm not convinced that it really makes sense to have PUBLICATION of a
>>> table be independent from the rights an owner of a table has. We don't
>>> allow other ALTER commands on objects based on GRANT'able rights, in
>>> general, so I'm not really sure that it makes sense to do so here.
>>
>> The REFERENCES and TRIGGER privileges are very similar in principle.
>
> TRIGGER is a great example of an, ultimately, poorly chosen privilege to
> GRANT away, with a good history of discussion about it:
>
> https://www.postgresql.org/message-id/21827.1166115978%40sss.pgh.pa.us
> https://www.postgresql.org/message-id/7389.1405554356%40sss.pgh.pa.us
>
> Further, how would RLS be handled with publication? I've been assuming
> that it's simply ignored, but that's clearly wrong if a non-owner can
> publish a table that they just have SELECT,PUBLISH on, isn't it?
>

I don't see why would PUBLISH care about RLS.

>>> The downside of adding these privileges is that we're burning through
>>> the last few bits in the ACLMASK for a privilege that doesn't really
>>> seem like it's something that would be GRANT'd in general usage.
>>
>> I don't see any reason why we couldn't increase the size of AclMode if
>> it becomes necessary.
>
> I've fought exactly that argument before and there is a good deal of
> entirely reasonable push-back on increasing our catalogs by so much.
>

Hmm to be honest I don't see what's the issue there.

>>> I'm certainly all for removing the need for users to be the superuser
>>> for such commands, just not sure that they should be GRANT'able
>>> privileges instead of privileges which the owner of the relation or
>>> database has.
>>
>> Then you couldn't set up a replication structure involving tables owned
>> by different users without resorting to blunt instruments like having
>> everything owned by the same user or using superusers.
>
> That's not correct- you would simply need a user who is considered an
> owner for all of the objects which you want to replicate, that doesn't
> have to be a *direct* owner or a superuser.
>
> The tables can have individual roles, with some admin role who is a
> member of those other roles, or another mechanism (as Simon has proposed
> not too long ago...) to have a given role be considered equivilant to an
> owner for all of the relations in a particular database.
>

I do agree with this though. And I also agree with the overall sentiment
that we don't need special PUBLICATION privilege on tables.

I do like the rest of the patch.

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