public inbox for [email protected]
help / color / mirror / Atom feed[PATCH v9 02/15] doc: pg_stat_progress_basebackup
6+ messages / 4 participants
[nested] [flat]
* [PATCH v9 02/15] doc: pg_stat_progress_basebackup
@ 2020-03-30 02:22 Justin Pryzby <[email protected]>
0 siblings, 0 replies; 6+ messages in thread
From: Justin Pryzby @ 2020-03-30 02:22 UTC (permalink / raw)
commit e65497df8f85ab9b9084c928ff69f384ea729b24
Author: Fujii Masao <[email protected]>
---
doc/src/sgml/monitoring.sgml | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/doc/src/sgml/monitoring.sgml b/doc/src/sgml/monitoring.sgml
index 673a0e73e4..4e0193a967 100644
--- a/doc/src/sgml/monitoring.sgml
+++ b/doc/src/sgml/monitoring.sgml
@@ -6089,8 +6089,8 @@ SELECT pg_stat_get_backend_pid(s.backendid) AS pid,
<entry><literal>waiting for checkpoint to finish</literal></entry>
<entry>
The WAL sender process is currently performing
- <function>pg_start_backup</function> to set up for
- taking a base backup, and waiting for backup start
+ <function>pg_start_backup</function> to prepare to
+ take a base backup, and waiting for the start-of-backup
checkpoint to finish.
</entry>
</row>
--
2.17.0
--L6iaP+gRLNZHKoI4
Content-Type: text/x-diff; charset=us-ascii
Content-Disposition: attachment;
filename="v9-0003-doc-Allow-users-to-limit-storage-reserved-by-repl.patch"
^ permalink raw reply [nested|flat] 6+ messages in thread
* Re: Non-superuser subscription owners
@ 2022-01-08 06:57 Amit Kapila <[email protected]>
2022-01-08 07:31 ` Re: Non-superuser subscription owners Jeff Davis <[email protected]>
0 siblings, 1 reply; 6+ messages in thread
From: Amit Kapila @ 2022-01-08 06:57 UTC (permalink / raw)
To: Mark Dilger <[email protected]>; +Cc: Jeff Davis <[email protected]>; Andrew Dunstan <[email protected]>; pgsql-hackers; Robert Haas <[email protected]>
On Thu, Dec 16, 2021 at 1:53 AM Mark Dilger
<[email protected]> wrote:
>
> > On Nov 24, 2021, at 4:30 PM, Jeff Davis <[email protected]> wrote:
> >
> > We need to do permission checking for WITH CHECK OPTION and RLS. The
> > patch right now allows the subscription to write data that an RLS
> > policy forbids.
>
> Version 4 of the patch, attached.
>
For Update/Delete, we do read the table first via
FindReplTupleInLocalRel(), so is there a need to check ACL_SELECT
before that?
--
With Regards,
Amit Kapila.
^ permalink raw reply [nested|flat] 6+ messages in thread
* Re: Non-superuser subscription owners
2022-01-08 06:57 Re: Non-superuser subscription owners Amit Kapila <[email protected]>
@ 2022-01-08 07:31 ` Jeff Davis <[email protected]>
2022-01-08 10:05 ` Re: Non-superuser subscription owners Amit Kapila <[email protected]>
0 siblings, 1 reply; 6+ messages in thread
From: Jeff Davis @ 2022-01-08 07:31 UTC (permalink / raw)
To: Amit Kapila <[email protected]>; Mark Dilger <[email protected]>; +Cc: Andrew Dunstan <[email protected]>; pgsql-hackers; Robert Haas <[email protected]>
On Sat, 2022-01-08 at 12:27 +0530, Amit Kapila wrote:
> For Update/Delete, we do read the table first via
> FindReplTupleInLocalRel(), so is there a need to check ACL_SELECT
> before that?
If it's logically an update/delete, then I think ACL_UPDATE/DELETE is
the right one to check. Do you have a different opinion?
Regards,
Jeff Davis
^ permalink raw reply [nested|flat] 6+ messages in thread
* Re: Non-superuser subscription owners
2022-01-08 06:57 Re: Non-superuser subscription owners Amit Kapila <[email protected]>
2022-01-08 07:31 ` Re: Non-superuser subscription owners Jeff Davis <[email protected]>
@ 2022-01-08 10:05 ` Amit Kapila <[email protected]>
2022-01-08 17:14 ` Re: Non-superuser subscription owners Jeff Davis <[email protected]>
0 siblings, 1 reply; 6+ messages in thread
From: Amit Kapila @ 2022-01-08 10:05 UTC (permalink / raw)
To: Jeff Davis <[email protected]>; +Cc: Mark Dilger <[email protected]>; Andrew Dunstan <[email protected]>; pgsql-hackers; Robert Haas <[email protected]>
On Sat, Jan 8, 2022 at 1:01 PM Jeff Davis <[email protected]> wrote:
>
> On Sat, 2022-01-08 at 12:27 +0530, Amit Kapila wrote:
> > For Update/Delete, we do read the table first via
> > FindReplTupleInLocalRel(), so is there a need to check ACL_SELECT
> > before that?
>
> If it's logically an update/delete, then I think ACL_UPDATE/DELETE is
> the right one to check. Do you have a different opinion?
>
But shouldn't we do it the first time before accessing the table?
--
With Regards,
Amit Kapila.
^ permalink raw reply [nested|flat] 6+ messages in thread
* Re: Non-superuser subscription owners
2022-01-08 06:57 Re: Non-superuser subscription owners Amit Kapila <[email protected]>
2022-01-08 07:31 ` Re: Non-superuser subscription owners Jeff Davis <[email protected]>
2022-01-08 10:05 ` Re: Non-superuser subscription owners Amit Kapila <[email protected]>
@ 2022-01-08 17:14 ` Jeff Davis <[email protected]>
2022-01-08 17:37 ` Re: Non-superuser subscription owners Tom Lane <[email protected]>
0 siblings, 1 reply; 6+ messages in thread
From: Jeff Davis @ 2022-01-08 17:14 UTC (permalink / raw)
To: Amit Kapila <[email protected]>; +Cc: Mark Dilger <[email protected]>; Andrew Dunstan <[email protected]>; pgsql-hackers; Robert Haas <[email protected]>
On Sat, 2022-01-08 at 15:35 +0530, Amit Kapila wrote:
> On Sat, Jan 8, 2022 at 1:01 PM Jeff Davis <[email protected]> wrote:
> >
> > On Sat, 2022-01-08 at 12:27 +0530, Amit Kapila wrote:
> > > For Update/Delete, we do read the table first via
> > > FindReplTupleInLocalRel(), so is there a need to check ACL_SELECT
> > > before that?
> >
> > If it's logically an update/delete, then I think ACL_UPDATE/DELETE
> > is
> > the right one to check. Do you have a different opinion?
> >
>
> But shouldn't we do it the first time before accessing the table?
I'm not sure I follow the reasoning. Are you saying that, to logically
replay a simple DELETE, the subscription owner should have SELECT
privileges on the destination table?
Is there a way that a subscription owner could somehow exploit a DELETE
privilege to see the contents of a table on which they have no SELECT
privileges? Or is it purely an internal read, which is necessary for
any ordinary local DELETE/UPDATE anyway?
Regards,
Jeff Davis
^ permalink raw reply [nested|flat] 6+ messages in thread
* Re: Non-superuser subscription owners
2022-01-08 06:57 Re: Non-superuser subscription owners Amit Kapila <[email protected]>
2022-01-08 07:31 ` Re: Non-superuser subscription owners Jeff Davis <[email protected]>
2022-01-08 10:05 ` Re: Non-superuser subscription owners Amit Kapila <[email protected]>
2022-01-08 17:14 ` Re: Non-superuser subscription owners Jeff Davis <[email protected]>
@ 2022-01-08 17:37 ` Tom Lane <[email protected]>
0 siblings, 0 replies; 6+ messages in thread
From: Tom Lane @ 2022-01-08 17:37 UTC (permalink / raw)
To: Jeff Davis <[email protected]>; +Cc: Amit Kapila <[email protected]>; Mark Dilger <[email protected]>; Andrew Dunstan <[email protected]>; pgsql-hackers; Robert Haas <[email protected]>
Jeff Davis <[email protected]> writes:
> I'm not sure I follow the reasoning. Are you saying that, to logically
> replay a simple DELETE, the subscription owner should have SELECT
> privileges on the destination table?
We consider that DELETE WHERE <condition> requires SELECT privilege
on the column(s) read by the <condition>. I suppose that the point
here is to enforce the same privilege checks that occur in normal
SQL operation, so yes.
> Is there a way that a subscription owner could somehow exploit a DELETE
> privilege to see the contents of a table on which they have no SELECT
> privileges?
BEGIN;
DELETE FROM tab WHERE col = 'foo';
-- note deletion count
ROLLBACK;
Now you have some information about whether "col" contains 'foo'.
Admittedly, it might be a pretty low-bandwidth way to extract data,
but we still regard it as a privilege issue.
regards, tom lane
^ permalink raw reply [nested|flat] 6+ messages in thread
end of thread, other threads:[~2022-01-08 17:37 UTC | newest]
Thread overview: 6+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2020-03-30 02:22 [PATCH v9 02/15] doc: pg_stat_progress_basebackup Justin Pryzby <[email protected]>
2022-01-08 06:57 Re: Non-superuser subscription owners Amit Kapila <[email protected]>
2022-01-08 07:31 ` Re: Non-superuser subscription owners Jeff Davis <[email protected]>
2022-01-08 10:05 ` Re: Non-superuser subscription owners Amit Kapila <[email protected]>
2022-01-08 17:14 ` Re: Non-superuser subscription owners Jeff Davis <[email protected]>
2022-01-08 17:37 ` Re: Non-superuser subscription owners Tom Lane <[email protected]>
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox