Re: copy.c handling for RLS is insecure - Mailing list pgsql-hackers

From Robert Haas
Subject Re: copy.c handling for RLS is insecure
Date
Msg-id CA+TgmobbQSEKQomROCGKwaM_tVaqKXXurR2WdGF5_gTgfgbgOA@mail.gmail.com
Whole thread Raw
In response to Re: copy.c handling for RLS is insecure  (Stephen Frost <sfrost@snowman.net>)
Responses Re: copy.c handling for RLS is insecure  (Stephen Frost <sfrost@snowman.net>)
List 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 by date:

Previous
From: Robert Haas
Date:
Subject: Re: dblink_get_connections() result for no connections
Next
From: Christoph Berg
Date:
Subject: Re: test_shm_mq failing on mips*