Re: [HACKERS] logical replication access control patches - Mailing list pgsql-hackers

From Petr Jelinek
Subject Re: [HACKERS] logical replication access control patches
Date
Msg-id d2281938-98ff-29b0-1df4-53d95867f03f@2ndquadrant.com
Whole thread Raw
In response to Re: [HACKERS] logical replication access control patches  (Stephen Frost <sfrost@snowman.net>)
Responses Re: [HACKERS] logical replication access control patches
List pgsql-hackers
On 28/02/17 04:10, Stephen Frost wrote:
> Peter,
> 
> * Peter Eisentraut (peter.eisentraut@2ndquadrant.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



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: [HACKERS] PATCH: two slab-like memory allocators
Next
From: Tom Lane
Date:
Subject: Re: [HACKERS] PATCH: two slab-like memory allocators