COPY command with RLS bug - Mailing list pgsql-hackers

From Adam Brightwell
Subject COPY command with RLS bug
Date
Msg-id CAE_9P=i9ZWrTJ-b2VgRPsT9-qLeQ9EwHeWLFimsjtuZKqnSnng@mail.gmail.com
Whole thread Raw
Responses Re: COPY command with RLS bug  (Simon Riggs <simon@2ndquadrant.com>)
List pgsql-hackers
All,

I have discovered a bug with the COPY command, specifically related to RLS.

The issue:

When running COPY as superuser on a table that has RLS enabled, RLS is
bypassed and therefore no issue exists.  However, when performing a
COPY as a non-privileged user on the same table causes issues when
more than one column is specified as part of the command.

Assuming:

CREATE TABLE foo (a int, b int, c int);

... set up RLS

Connecting as a non-privileged user provides the following results:

COPY foo TO stdout; -- pass
COPY foo (a) TO stdout; -- pass
COPY foo (a, b, c) TO stdout; -- fail

The error related to the failure is the following:

ERROR:  missing FROM-clause entry for table "b"
LINE 1: copy foo (a, b, c) to stdout;

I don't believe this to be a vulnerability simply because it doesn't
'leak' any data to a non-privileged user, it will just throw an error.
As well, this is only an issue when more than one column is specified
and '*' isn't implied. I have attached a 'test' file that can be used
to observe this behavior.

I have verified that this is an issue on REL9_5_STABLE, REL9_6_STABLE
and master.

Solution:

The issue seems to be that the target list for the resulting SELECT
statement is not being built correctly. I have attached a proposed
patch to fix this issue.  As well, I have added a few regression tests
for this case.

If deemed appropriate, then I'll add this to the currently open Commitfest.

Please let me know if there are any questions.

Thanks,
Adam

Attachment

pgsql-hackers by date:

Previous
From: Jeff Janes
Date:
Subject: Re: Write Ahead Logging for Hash Indexes
Next
From: Tom Lane
Date:
Subject: Re: Preventing deadlock on parallel backup