Re: API change advice: Passing plan invalidation info from the rewriter into the planner? - Mailing list pgsql-hackers

From Stephen Frost
Subject Re: API change advice: Passing plan invalidation info from the rewriter into the planner?
Date
Msg-id CAOuzzgqO7i7SjBegshf3KUBkL_KyZGgsWkgYgHAQ4hn=4Htkyw@mail.gmail.com
Whole thread Raw
In response to Re: API change advice: Passing plan invalidation info from the rewriter into the planner?  (Gregory Smith <gregsmithpgsql@gmail.com>)
Responses Re: API change advice: Passing plan invalidation info from the rewriter into the planner?  (Dean Rasheed <dean.a.rasheed@gmail.com>)
Re: API change advice: Passing plan invalidation info from the rewriter into the planner?  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
Greg, all,

I will reply to the emails in detail when I get a chance but am out of town at a funeral, so it'll likely be delayed. I did want to echo my agreement for the most part with Greg and in particular...

On Thursday, June 12, 2014, Gregory Smith <gregsmithpgsql@gmail.com> wrote:
On 6/11/14, 10:26 AM, Robert Haas wrote:
Now, as soon as we introduce the concept that selecting from a table might not really mean "read from the table" but "read from the table after applying this owner-specified qual", we're opening up a whole new set of attack surfaces. Every pg_dump is an opportunity to hack somebody else's account, or at least audit their activity.

I'm in full agreement we should clearly communicate the issues around pg_dump in particular, because they can't necessarily be eliminated altogether without some major work that's going to take a while to finish.  And if the work-around is some sort of GUC for killing RLS altogether, that's ugly but not unacceptable to me as a short-term fix.

A GUC which is enable / disable / error-instead may work quiet well, with error-instead for pg_dump default if people really want it (there would have to be a way to disable that though, imv).

Note that enable is default in general, disable would be for superuser only (or on start-up) to disable everything, and error-instead anyone could use but it would error instead of implementing RLS when querying an RLS-enabled table. 

This approach was suggested by an existing user testing out this RLS approach, to be fair, but it looks pretty sane to me as a way to address some of these concerns. Certainly open to other ideas and thoughts though. 

Thanks,

Stephen

pgsql-hackers by date:

Previous
From: Shreesha
Date:
Subject: How to change the pgsql source code and build it??
Next
From: Abhijit Menon-Sen
Date:
Subject: Re: How to change the pgsql source code and build it??