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 9ea9cc5d-6acb-d8f5-c2dc-810167683fbd@2ndquadrant.com
Whole thread Raw
In response to Re: [HACKERS] logical replication access control patches  (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>)
Responses Re: [HACKERS] logical replication access control patches  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
On 10/03/17 20:02, Peter Eisentraut wrote:
> On 2/27/17 22: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
> 
> Those discussions about the trigger privileges are valid, but the actual
> reason why this is a problem is because our trigger implementation is
> broken by default.  In the SQL standard, triggers are executed as the
> table owner, so the trigger procedure does not have full account access
> to the role that is causing the trigger to fire.  This is an independent
> problem that deserves consideration, but it does not invalidate the kind
> of privilege that can be granted.
> 
>>> 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'm not really following what you are saying here.  It seems to me that
> you are describing a new kind of facility that gives a role a given
> capability with respect to a table.
> 
> If so, we already have that, namely privileges.  If not, please elaborate.
> 

My understanding of what Shephen is proposing is, you have "ownerA" of
tableA and "ownerB" of tableB, then you want role "publishe"r to be able
to publish those, so you simply grant it the "ownerA" and "ownerB"
roles. Obviously that might is many situations mean that the "publisher"
role potentially also gets sweeping privileges to other tables which may
not be desirable.

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



pgsql-hackers by date:

Previous
From: Pavan Deolasee
Date:
Subject: Re: [HACKERS] Patch: Write Amplification Reduction Method (WARM)
Next
From: Robert Haas
Date:
Subject: Re: [HACKERS] Parallel seq. plan is not coming against inheritance orpartition table