On 2021-Dec-18, Tomas Vondra wrote:
> On 12/18/21 02:34, Alvaro Herrera wrote:
> > On 2021-Dec-17, Tomas Vondra wrote:
> > > > If the server has a *separate* security mechanism to hide the
> > > > columns (per-column privs), it is that feature that will protect
> > > > the data, not the logical-replication-feature to filter out
> > > > columns.
> > >
> > > Right. Although I haven't thought about how logical decoding
> > > interacts with column privileges. I don't think logical decoding
> > > actually checks column privileges - I certainly don't recall any
> > > ACL checks in src/backend/replication ...
> >
> > Well, in practice if you're confronted with a replica that's
> > controlled by a malicious user that can tweak its behavior, then
> > replica-side privilege checking won't do anything useful.
>
> I don't follow. Surely the decoding happens on the primary node,
> right? Which is where the ACL checks would happen, using the role the
> replication connection is opened with.
I think you do follow. Yes, the decoding happens on the primary node,
and the security checks should occur in the primary node, because to do
otherwise is folly(*). Which means that column filtering, being a
replica-side feature, is *not* a security feature. I was mistaken about
it, is all. If you want security, you need to use column-level
privileges, as you say.
(*) The checks *must* occur in the primary side, because the primary
does not control the code that runs in the replica side. The primary
must treat the replica as running potentially hostile code. Trying to
defend against that is not practical.
--
Álvaro Herrera PostgreSQL Developer — https://www.EnterpriseDB.com/