Re: Privileges on PUBLICATION
Peter Eisentraut <peter.eisentraut@enterprisedb.com>
From: Peter Eisentraut <peter.eisentraut@enterprisedb.com>
To: Antonin Houska <ah@cybertec.at>
Cc: Euler Taveira <euler@eulerto.com>, Amit Kapila <amit.kapila16@gmail.com>,
PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2022-11-11T14:08:16Z
Lists: pgsql-hackers
On 04.11.22 08:28, Antonin Houska wrote: > I thought about the whole concept a bit more and I doubt if the PUBLICATION > privilege is the best approach. In particular, the user specified in CREATE > SUBSCRIPTION ... CONNECTION ... (say "subscription user") needs to have SELECT > privilege on the tables replicated. So if the DBA excludes some columns from > the publication's column list and sets the (publication) privileges in such a > way that the user cannot get the column values via other publications, the > user still can connect to the database directly and get values of the excluded > columns. Why are the SELECT privileges needed? Maybe that's something to think about and maybe change. > As an alternative to the publication privileges, I think that the CREATE > SUBSCRIPTION command could grant ACL_SELECT automatically to the subscription > user on the individual columns contained in the publication column list, and > DROP SUBSCRIPTION would revoke that privilege. I think that approach is weird and unusual. Privileges and object creation should be separate operations.
Commits
-
Refactor ExecGrant_*() functions
- 369f09e420ef 16.0 cited
-
doc: Add note about lack of publication privileges
- 84387fc88944 16.0 landed