From 53a53ea332131b3d29d8d69e1dc2823f4d6ff21a Mon Sep 17 00:00:00 2001 From: Tom Lane Date: Fri, 10 Mar 2023 13:52:28 -0500 Subject: Ensure COPY TO on an RLS-enabled table copies no more than it should. The COPY documentation is quite clear that "COPY relation TO" copies rows from only the named table, not any inheritance children it may have. However, if you enabled row-level security on the table then this stopped being true, because the code forgot to apply the ONLY modifier in the "SELECT ... FROM relation" query that it constructs in order to allow RLS predicates to be attached. Fix that. Report and patch by Antonin Houska (comment adjustments and test case by me). Back-patch to all supported branches. Discussion: https://postgr.es/m/3472.1675251957@antos --- src/backend/commands/copyto.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to 'src/backend/commands/copyto.c') diff --git a/src/backend/commands/copyto.c b/src/backend/commands/copyto.c index b6a4b77053a..a9f422b71ce 100644 --- a/src/backend/commands/copyto.c +++ b/src/backend/commands/copyto.c @@ -508,8 +508,8 @@ BeginCopyTo(ParseState *pstate, /* * With row-level security and a user using "COPY relation TO", we * have to convert the "COPY relation TO" to a query-based COPY (eg: - * "COPY (SELECT * FROM relation) TO"), to allow the rewriter to add - * in any RLS clauses. + * "COPY (SELECT * FROM ONLY relation) TO"), to allow the rewriter to + * add in any RLS clauses. * * When this happens, we are passed in the relid of the originally * found relation (which we have locked). As the planner will look up -- cgit v1.2.3