On 14.03.23 19:30, Gregory Stark (as CFM) wrote:
FYI this looks like it needs a rebase due to a conflict in copy.c and
an offset in pgoutput.c.
Is there anything specific that still needs review or do you think
you've handled all Peter's concerns? In particular, is there "a
comprehensive descrip
+-+-+---+--
- postgres | f | t | t | t | t | f
+ Owner | All tables | Inserts | Updates | Deletes | Truncates | Via root |
Access privileges
+--++-+-+-+---+
FYI this looks like it needs a rebase due to a conflict in copy.c and
an offset in pgoutput.c.
Is there anything specific that still needs review or do you think
you've handled all Peter's concerns? In particular, is there "a
comprehensive description of what it is trying to do"? :)
On 16.12.22 17:37, Antonin Houska wrote:
This is v4. The patch had to be rebased due to the commit 369f09e420.
I think what this patch set needs first of all is a comprehensive
description of what it is trying to do, exactly what commands and
behaviors it adds, what are some of the subtleties
Antonin Houska wrote:
> Antonin Houska wrote:
>
> > Peter Eisentraut wrote:
> >
> > > 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
Antonin Houska wrote:
> Peter Eisentraut wrote:
>
> > 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 ...
Peter Eisentraut wrote:
> 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
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 r
Mark Dilger wrote:
> > On Nov 4, 2022, at 12:28 AM, 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 us
> On Nov 4, 2022, at 12:28 AM, 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
>
Amit Kapila wrote:
> On Thu, Nov 3, 2022 at 11:12 AM Antonin Houska wrote:
> >
> > Peter Eisentraut wrote:
> >
> > > The CF entry is about privileges on publications. Please rebase that
> > > patch
> > > and repost it so that the CF app and the CF bot are up to date.
> >
> > The rebased patch
Peter Eisentraut wrote:
> On 03.11.22 01:43, Antonin Houska wrote:
> > Peter Eisentraut wrote:
> >
> >> The CF entry is about privileges on publications. Please rebase that patch
> >> and repost it so that the CF app and the CF bot are up to date.
> > The rebased patch (with regression tests a
On Thu, Nov 3, 2022 at 9:19 PM Peter Eisentraut
wrote:
>
> On 03.11.22 01:43, Antonin Houska wrote:
> > Peter Eisentraut wrote:
> >
> >> The CF entry is about privileges on publications. Please rebase that patch
> >> and repost it so that the CF app and the CF bot are up to date.
> >
> > The reb
On Thu, Nov 3, 2022 at 11:12 AM Antonin Houska wrote:
>
> Peter Eisentraut wrote:
>
> > The CF entry is about privileges on publications. Please rebase that patch
> > and repost it so that the CF app and the CF bot are up to date.
>
> The rebased patch (with regression tests added) is attached h
On 03.11.22 01:43, Antonin Houska wrote:
Peter Eisentraut wrote:
The CF entry is about privileges on publications. Please rebase that patch
and repost it so that the CF app and the CF bot are up to date.
The rebased patch (with regression tests added) is attached here.
Some preliminary di
e table to
+ the publication, be aware that other publications in the same database
+ could expose the same
+ information. Privileges on publication can
+ be used to implement finer-grained access control.
diff --git a/doc/src/sgml/ref/grant.sgml b/doc/src/sgml/ref/grant.sgml
ind
On 20.06.22 16:01, Antonin Houska wrote:
On Wed, May 18, 2022, at 6:44 AM, Antonin Houska wrote:
ok, please see the next version.
The new paragraph looks good to me. I'm not sure if the CREATE PUBLICATION is
the right place to provide such information. As I suggested in a previous email
[1], yo
,6 +1171,17 @@ CONTEXT: processing remote data for replication origin "pg_16395" during "INSER
schema automatically, the user must be a superuser.
+
+ Note that there are currently no privileges on publication, and that any
+ subscriber can access any publication. Thus if you&
Euler Taveira wrote:
> On Wed, May 18, 2022, at 6:16 AM, Antonin Houska wrote:
>
> The patch is attached to this message.
>
> Great. Add it to the next CF. I'll review it when I have some spare time.
https://commitfest.postgresql.org/38/3641/
Thanks!
--
Antonin Houska
Web: https://www.cybe
On Wed, May 18, 2022, at 6:44 AM, Antonin Houska wrote:
> ok, please see the next version.
The new paragraph looks good to me. I'm not sure if the CREATE PUBLICATION is
the right place to provide such information. As I suggested in a previous email
[1], you could add it to "Logical Replication > Se
On Wed, May 18, 2022, at 6:16 AM, Antonin Houska wrote:
> The patch is attached to this message.
Great. Add it to the next CF. I'll review it when I have some spare time.
--
Euler Taveira
EDB https://www.enterprisedb.com/
+
+
+ Note that there are currently no privileges on publication, and that any
+ subscriber can access any publication. Thus if you're trying to hide
+ some information from particular subscribers (by using the
+ WHERE clause or the column list, or by not adding the
0644
--- a/doc/src/sgml/ref/grant.sgml
+++ b/doc/src/sgml/ref/grant.sgml
@@ -82,6 +82,11 @@ GRANT { { SET | ALTER SYSTEM } [, ... ] | ALL [ PRIVILEGES ] }
TO role_specification [, ...] [ WITH GRANT OPTION ]
[ GRANTED BY role_specification ]
+GRANT { USAGE | ALL [ PRIVILEGES ] }
+ON PU
On Fri, May 13, 2022, at 3:36 AM, Antonin Houska wrote:
> Attached is my proposal. It tries to be more specific and does not mention the
> absence of the privileges explicitly.
You explained the current issue but say nothing about the limitation. This
information will trigger a question possibly in
Peter Eisentraut wrote:
> On 10.05.22 10:37, Antonin Houska wrote:
> > My understanding is that the rows/columns filtering is a way for the
> > *publisher* to control which data is available to particular replica. From
> > this point of view, the publication privileges would just make the contro
Euler Taveira wrote:
> On Tue, May 10, 2022, at 5:37 AM, Antonin Houska wrote:
>
> My understanding is that the rows/columns filtering is a way for the
> *publisher* to control which data is available to particular replica. From
> this point of view, the publication privileges would just make
On Tue, May 10, 2022, at 5:37 AM, Antonin Houska wrote:
> My understanding is that the rows/columns filtering is a way for the
> *publisher* to control which data is available to particular replica. From
> this point of view, the publication privileges would just make the control
> complete.
I agre
On 10.05.22 10:37, Antonin Houska wrote:
My understanding is that the rows/columns filtering is a way for the
*publisher* to control which data is available to particular replica. From
this point of view, the publication privileges would just make the control
complete.
I think privileges on pu
Amit Kapila wrote:
> On Tue, May 10, 2022 at 12:16 AM Euler Taveira wrote:
> >
> > On Mon, May 9, 2022, at 11:09 AM, Antonin Houska wrote:
> >
> > Now that the user can specify rows and columns to be omitted from the
> > logical
> > replication [1], I suppose hiding rows and columns from the su
ser)."
>
> You can use role foo for the replication connection but role foo couldn't be a
> superuser. In this case, even if role foo open a connection to database
> postgres, a publication cannot be created due to lack of privileges.
>
> Don't we need privilege
On Tue, May 10, 2022 at 12:16 AM Euler Taveira wrote:
>
> On Mon, May 9, 2022, at 11:09 AM, Antonin Houska wrote:
>
> Now that the user can specify rows and columns to be omitted from the logical
> replication [1], I suppose hiding rows and columns from the subscriber is an
> important use case. H
en a connection to database
postgres, a publication cannot be created due to lack of privileges.
> Don't we need privileges on publication (e.g GRANT USAGE ON PUBLICATION ...)
> now?
Maybe. We rely on CREATE privilege on databases right now. If you say that
GRANT USAGE ON PUBLICATION is jus
... command) needs
SELECT permission on the replicated table (on the publication side), he can
just use another publication (which has different filters or no filters at
all) to get the supposedly-hidden data replicated.
Don't we need privileges on publication (e.g GRANT USAGE ON PUBLICATION ...)
now
33 matches
Mail list logo
