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

From Peter Eisentraut
Subject Re: [HACKERS] logical replication access control patches
Date
Msg-id c4b642fe-29ba-ffa5-51db-fabf9912a167@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  (Petr Jelinek <petr.jelinek@2ndquadrant.com>)
List pgsql-hackers
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.

-- 
Peter Eisentraut              http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: [HACKERS] Bizarre choice of case for RELKIND_PARTITIONED_TABLE
Next
From: Peter Eisentraut
Date:
Subject: Re: [HACKERS] logical replication access control patches