Re: logical replication access control patches

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?

> > 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.

> > 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.

Thanks!

Stephen