Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1VHEQC-0003zq-3h for pgsql-hackers@arkaria.postgresql.org; Wed, 04 Sep 2013 14:51:04 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.80) (envelope-from ) id 1VHEQB-0003GH-K8 for pgsql-hackers@arkaria.postgresql.org; Wed, 04 Sep 2013 14:51:03 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1VHEQA-0003G9-R4 for pgsql-hackers@postgresql.org; Wed, 04 Sep 2013 14:51:02 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by magus.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1VHEQ4-000433-K9 for pgsql-hackers@postgresql.org; Wed, 04 Sep 2013 14:51:02 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.14.4/8.14.4) with ESMTP id r84EonQV001544; Wed, 4 Sep 2013 10:50:49 -0400 From: Tom Lane To: Robert Haas cc: Stephen Frost , Josh Berkus , Kohei KaiGai , "ktm@rice.edu" , Alexander Korotkov , Oleg Bartunov , Greg Smith , PgHacker Subject: Re: [v9.4] row level security In-reply-to: References: <20130829142321.GA30496@aart.rice.edu> <521F7DFB.8060602@agliodbs.com> <5220D832.7090104@agliodbs.com> <20130830192729.GO2706@tamriel.snowman.net> <16798.1377891794@sss.pgh.pa.us> <1398.1378305956@sss.pgh.pa.us> Comments: In-reply-to Robert Haas message dated "Wed, 04 Sep 2013 10:48:47 -0400" Date: Wed, 04 Sep 2013 10:50:49 -0400 Message-ID: <1543.1378306249@sss.pgh.pa.us> X-Pg-Spam-Score: -4.3 (----) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-hackers Precedence: bulk Sender: pgsql-hackers-owner@postgresql.org Robert Haas writes: > On Wed, Sep 4, 2013 at 10:45 AM, Tom Lane wrote: >> Well, the security-barrier view stuff did not present itself as a 100% >> solution. But perhaps more to the point, it was conceptually simple to >> implement, ie don't flatten views if they have this bit set, and don't >> push down quals into such sub-selects unless they're marked leakproof. > Right. IMHO, this new feature should be similarly simple: when an > unprivileged user references a table, treat that as a reference to a > leakproof view over the table, with the RLS qual injected into the > view. And for insert/update/delete, we do what exactly? regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers