COPY command with RLS bug
От | Adam Brightwell |
---|---|
Тема | COPY command with RLS bug |
Дата | |
Msg-id | CAE_9P=i9ZWrTJ-b2VgRPsT9-qLeQ9EwHeWLFimsjtuZKqnSnng@mail.gmail.com обсуждение исходный текст |
Ответы |
Re: COPY command with RLS bug
|
Список | 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
Вложения
В списке pgsql-hackers по дате отправления: