Re: copy.c handling for RLS is insecure
От | Robert Haas |
---|---|
Тема | Re: copy.c handling for RLS is insecure |
Дата | |
Msg-id | CA+TgmobbQSEKQomROCGKwaM_tVaqKXXurR2WdGF5_gTgfgbgOA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: copy.c handling for RLS is insecure (Stephen Frost <sfrost@snowman.net>) |
Ответы |
Re: copy.c handling for RLS is insecure
|
Список | pgsql-hackers |
On Thu, Nov 27, 2014 at 2:03 AM, Stephen Frost <sfrost@snowman.net> wrote: > Alright, I've done the change to use the RangeVar from CopyStmt, but > also added a check wherein we verify that the relation's OID returned > from the planned query is the same as the relation's OID that we did the > RLS check on- if they're different, we throw an error. Please let me > know if there are any remaining concerns. That's clearly an improvement, but I'm not sure it's water-tight. What if the name that originally referenced a table ended up referencing a view? Then you could get list_length(plan->relationOids) != 1. (And, in that case, I also wonder if you could get eval_const_expressions() to do evil things on your behalf while planning.) -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: