Date: Thu, 8 Sep 2016 16:09:12 -0400
From: Stephen Frost <sfrost@snowman.net>
To: Alvaro Herrera <alvherre@2ndquadrant.com>
Cc: Robert Haas <robertmhaas@gmail.com>, Thom Brown <thom@linux.com>,
	"pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Subject: Re: Add support for restrictive RLS policies
Message-ID: <20160908200912.GW4028@tamriel.snowman.net>
References: <20160908183544.GU4028@tamriel.snowman.net>
 <20160908192157.GA53172@alvherre.pgsql>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="4ig7IzjzLjn/qCC3"
Content-Disposition: inline
In-Reply-To: <20160908192157.GA53172@alvherre.pgsql>
User-Agent: Mutt/1.5.21 (2010-09-15)
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org


--4ig7IzjzLjn/qCC3
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Alvaro,

* Alvaro Herrera (alvherre@2ndquadrant.com) wrote:
> Stephen Frost wrote:
> > * Stephen Frost (sfrost@snowman.net) wrote:
> > > Based on Robert's suggestion and using Thom's verbiage, I've tested t=
his
> > > out:
> > >=20
> > > CREATE POLICY pol ON tab AS [PERMISSIVE|RESTRICTIVE] ...
>=20
> Can't you keep those words as Sconst or something (DefElems?) until the
> execution phase, so that they don't need to be keywords at all?  I'm
> fairly sure we do that kind of thing elsewhere.  Besides, that let you
> throw errors such as "keyword 'foobarive' not recognized" instead of a
> generic "syntax error" if the user enters a bogus permissivity (?)
> keyword.

Seems like we could do that, though I'm not convinced that it really
gains us all that much.  These are only unreserved keywords, of course,
so they don't impact users the way reserved keywords (of any kind) can.
While there may be some places where we use a string to represent a set
of defined options, I don't believe that's typical- certainly something
like DISCARD has a set of explicit values, same for CASCADE vs.
RESTRICT, replica_identity, TableLikeOption, etc..

We do have a few 'not recognized' messages in the backend, though
they're usually 'option %s not recognized' (there aren't any which use
'keyword') and they're in places where we support a list of options to
be specified (which also means they require additional code to check for
conflicting/redundant options).  We could possibly rearrange the entire
CREATE POLICY comamnd to use a list of options instead, along the lines
of what we do for views:

CREATE POLICY p1 ON t1
WITH (command=3Dselect,combine_using=3DAND)
USING ...;

but that hardly seems better.

Perhaps I'm not understanding what you're getting at though- is there
something in the existing grammar, in particular, that you're comparing
this to?

> Is the permissive/restrictive dichotomy enough to support all
> interesting use cases?  What I think is the equivalent concept in PAM
> uses required/requisite/sufficient/optional as possibilities, which
> allows for finer grained control.  Even there that's just the historical
> interface, and the replacement syntax has more gadgets.

Restrictive vs. Permissive very simply maps to the logical AND and OR
operators.  Those are the only binary logical operators we have and it
seems unlikely that we're going to get any more anytime soon.

I don't believe the comparison to PAM is really fair, as PAM is trying
to support the flexibility we already have by allowing users to specify
an expression in the policy itself.

Perhaps we may wish to come up with a more complex approach for how to
combine policies, but in that case, I'd think we'd do something like:

CREATE POLICY p1 ON t1 COMBINING ((policy1 AND policy2) OR policy3);

though I've not yet come across a case that requires something more
complicated than what we can do already with policies and the
restrictive / permissive options (note that the case above can be
handled that way, in fact, by making policy1 and policy2 restrictive and
policy3 permissive).  Perhaps that's because that more complicated logic
is generally understood and expected to be part of the policy expression
itself instead.

Also, as mentioned at the start of this thread, the capability for
restrictive policies has existed since 9.5, this change is simply
exposing that to users without having to require using an extension.

Thanks!

Stephen

--4ig7IzjzLjn/qCC3
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBCgAGBQJX0cVnAAoJEO1sijiDR2RVfq0P/0ia+h/SGCTdDOAlcPWVz3U6
RdNspwnjkrdyF/rqHY5zXYzzJolkSqGD0WFsxmgATTiksmOH36xMkhmPSxnftIkw
frAltVu7DtNhswqDNEt0IMUXNTEggLKPo2UdHeZcXxKlbwhPNG7mm2ExMH2WkDYh
k+RTBMWtGSn8sCQUs7mjwWuvT80pJiSUTXKIK9I4rpvVjtjgc/u/JHpJ29WUyWWR
57fVezwXPisFrjhj8mbU84pKN9Imj9AT+FjnUklleHcb0Kx8npsDcikhZ+b2cMip
1iOi9WK/5Ysq8BFVmQ9+2+CHqtBhzkfLjzQXfm51m/m925dO82tetphAKExDQsV8
bQULDCcal3M6cd46KJlfoK3Gdjm81Yaj7WlcHW19dKyKW+/7Ta6dzhVGinUQ0W4Q
4lj18KgIojF1NcjY1Yi9lW09B1DWGrVdl383HFYRoT5gsfFj216eWeydd8XJirVV
HJBrCO82SrEQlpndrIt2yYUpdytSnBniSbbgXHMVcfou98rCeneW4dMl7VDWF91j
2bF+7l/V+ahLAexQuVmTS13Ie6B+pju1OnfYkXopNRpf7Ls8VzYEtxnwgw/JGS2H
OMxKYmp2qaD1iOGvHdyTMVx6NL9fpEf/VQA5dFLWsvEvtSqD7xF+NVhlSyLC9s4m
o+GrUzQrS+DW1J6CZfkn
=96aL
-----END PGP SIGNATURE-----

--4ig7IzjzLjn/qCC3--