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

* Petr Jelinek (petr.jelinek@2ndquadrant.com) wrote:
> 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.

Perhaps I'm missing something here, in which case I would certainly
welcome some clarification, but in curreng PG I can GRANT you access to
a table and then limit what you can see with it using RLS and policies.

If I then GRANT you the PUBLISH right- shouldn't that also respect the
RLS setting and the policies set on the table?  Otherwise, PUBLISH is
allowing you to gain access to the data in the table that you wouldn't
normally be able to see with a simple SELECT.

We don't really even need to get to the RLS level to consider this
situation- what about column-level privileges?

Will users really understand that the PUBLISH right actually allows
complete access to the entire relation, rather than just the ability for
a user to PUBLISH what they are currently about to SELECT?  It certainly
doesn't seem intuitive to me, which is why I am concerned that it's
going to lead to confusion and bug/security reports down the road, or,
worse, poorly configured systems.

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

It's a not-insignificant increase in our system catalog data, plus a
bunch of work for whomever ends up being the one to want to push us
over.  The other approach would be to make the ACL system understand
that not every privilege applies to every object, but that's would also
be a bunch of work (most likely more...).

Thanks!

Stephen