Received: from malur.postgresql.org ([217.196.149.56])
	by arkaria.postgresql.org with esmtp (Exim 4.84_2)
	(envelope-from
 <pgsql-hackers-owner+M307151=pgsql-hackers-arkari@postgresql.org>)
	id 1boclv-0002Jc-QE
	for pgsql-hackers@arkaria.postgresql.org; Mon, 26 Sep 2016 20:45:07 +0000
Received: from localhost ([127.0.0.1] helo=postgresql.org)
	by malur.postgresql.org with smtp (Exim 4.84_2)
	(envelope-from
 <pgsql-hackers-owner+M307151=pgsql-hackers-arkari@postgresql.org>)
	id 1boclv-0006dy-6I
	for pgsql-hackers@arkaria.postgresql.org; Mon, 26 Sep 2016 20:45:07 +0000
Received: from makus.postgresql.org ([2001:4800:1501:1::229])
	by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256)
	(Exim 4.84_2)
	(envelope-from <alvherre@alvh.no-ip.org>)
	id 1bockX-0004VH-9V
	for pgsql-hackers@postgresql.org; Mon, 26 Sep 2016 20:43:41 +0000
Received: from smtprelay0190.b.hostedemail.com ([64.98.42.190]
 helo=smtprelay.b.hostedemail.com)
	by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256)
	(Exim 4.84_2)
	(envelope-from <alvherre@alvh.no-ip.org>)
	id 1bockU-0000Mr-4y
	for pgsql-hackers@postgresql.org; Mon, 26 Sep 2016 20:43:39 +0000
Received: from filter.hostedemail.com (10.5.19.248.rfc1918.com [10.5.19.248])
	by smtprelay01.b.hostedemail.com (Postfix) with ESMTP id 0245F2D2A1C;
	Mon, 26 Sep 2016 20:43:33 +0000 (UTC)
X-Session-Marker: 616C76686572726540616C76682E6E6F2D69702E6F7267
X-Spam-Summary: 
 50,0,0,,d41d8cd98f00b204,alvherre@alvh.no-ip.org,:::::::::::,RULES_HIT:41:355:379:599:800:960:967:973:981:988:989:1260:1277:1311:1312:1313:1314:1345:1359:1437:1515:1516:1518:1519:1534:1542:1593:1594:1595:1596:1711:1712:1730:1747:1777:1792:2393:2525:2560:2563:2682:2685:2692:2693:2828:2859:2892:2901:2910:2933:2937:2939:2942:2945:2947:2951:2954:3022:3138:3139:3140:3141:3142:3355:3865:3866:3867:3868:3870:3871:3872:3873:3874:3934:3936:3938:3941:3944:3947:3950:3953:3956:3959:4250:4605:5007:6119:6120:6261:7875:7901:7903:8526:9025:9121:10004:10400:10848:11026:11232:11658:11914:12296:12663:13439:13894:13895:14093:14097:14721:14819:21063:21080:21324:21450:30051:30054:30070:30075,0,RBL:none,CacheIP:none,Bayesian:0.5,0.5,0.5,Netcheck:none,DomainCache:0,MSF:not
 bulk,SPF:fn,MSBL:0,DNSBL:none,Custom_rules:0:0:0,LFtime:2,LUA_SUMMARY:none
X-HE-Tag: paste75_593727a29ef53
X-Filterd-Recvd-Size: 3669
Received: from alvin.alvh.no-ip.org (unknown [216.155.90.98])
	(Authenticated sender: alvherre@alvh.no-ip.org)
	by omf08.b.hostedemail.com (Postfix) with ESMTPA;
	Mon, 26 Sep 2016 20:43:33 +0000 (UTC)
Received: by alvin.alvh.no-ip.org (Postfix, from userid 1000)
	id 09422640; Mon, 26 Sep 2016 17:43:31 -0300 (CLST)
Date: Mon, 26 Sep 2016 17:43:31 -0300
From: Alvaro Herrera <alvherre@2ndquadrant.com>
To: Stephen Frost <sfrost@snowman.net>
Cc: Jeevan Chalke <jeevan.chalke@enterprisedb.com>,
	Robert Haas <robertmhaas@gmail.com>, Tom Lane <tgl@sss.pgh.pa.us>,
	Thom Brown <thom@linux.com>,
	"pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Subject: Re: Add support for restrictive RLS policies
Message-ID: <20160926204331.GA178854@alvherre.pgsql>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20160926200630.GM5148@tamriel.snowman.net>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Pg-Spam-Score: -0.4 (/)
List-Archive: <http://archives.postgresql.org/pgsql-hackers>
List-Help: <mailto:majordomo@postgresql.org?body=help>
List-ID: <pgsql-hackers.postgresql.org>
List-Owner: <mailto:pgsql-hackers-owner@postgresql.org>
List-Post: <mailto:pgsql-hackers@postgresql.org>
List-Subscribe: <mailto:majordomo@postgresql.org?body=sub%20pgsql-hackers>
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-hackers>
X-Mailing-List: pgsql-hackers
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org

Stephen Frost wrote:

> * Alvaro Herrera (alvherre@2ndquadrant.com) wrote:
> > Stephen Frost wrote:

> > > +     <para>
> > > +      If the policy is a "permissive" or "restrictive" policy.  Permissive
> > > +      policies are the default and always add visibillity- they ar "OR"d
> > > +      together to allow the user access to all rows through any of the
> > > +      permissive policies they have access to.  Alternativly, a policy can
> > > +      instead by "restrictive", meaning that the policy will be "AND"d
> > > +      with other restrictive policies and with the result of all of the
> > > +      permissive policies on the table.
> > > +     </para>
> > > +    </listitem>
> > > +   </varlistentry>

Stephen,

> > I dislike the "AND"d and "OR"d spelling of those terms.  Currently they
> > only appear in comments within rowsecurity.c (of your authorship too, I
> > imagine).  I think it'd be better to find actual words for those
> > actions.
> 
> I'm certainly open to suggestions, should you, or anyone else, have
> them.  I'll try and come up with something else, but that really is what
> we're doing- literally using either AND or OR to join the expressions
> together.

I understand, but the words "and" and "or" are not verbs.  I don't know
what are good verbs to use for this but I suppose there must be verbs
related to "conjunction" and "disjunction" ("to conjoin" and "to
disjoin" appear in the Merriam-Webster dictionary but I don't think they
represent the operation very well).  Maybe some native speaker would
have a better suggestion.

> > I don't understand this part.  Didn't you say previously that we already
> > had this capability in 9.5 and you were only exposing it over SQL?  If
> > that is true, how come you need to add a new column to this catalog?
> 
> The capability exists in 9.5 through hooks which are available to
> extensions, see the test_rls_hooks extension.  Those hooks are called
> every time and therefore don't require the information about restrictive
> policies to be tracked in pg_policy, and so they weren't.  Since this is
> adding support for users to define restrictive policies, we need to save
> those policies and therefore we need to distinguish which policies are
> restrictive and which are permissive, hence the need to modify pg_policy
> to track that information.

Ah, okay.  I thought you meant that it was already possible to create a
policy to behave this way, just not using SQL-based DDL.

-- 
Álvaro Herrera                https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers