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]> 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 07:31 Jeff Davis <[email protected]> parent: 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 10:05 Amit Kapila <[email protected]> parent: 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 17:14 Jeff Davis <[email protected]> parent: Amit Kapila <[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 17:37 Tom Lane <[email protected]> parent: Jeff Davis <[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