Date: Sun, 4 Sep 2016 11:01:13 -0400
From: Stephen Frost <sfrost@snowman.net>
To: Robert Haas <robertmhaas@gmail.com>, Thom Brown <thom@linux.com>
Cc: "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Subject: Re: Add support for restrictive RLS policies
Message-ID: <20160904150113.GM4028@tamriel.snowman.net>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="RJnWrOMAazItjkl+"
Content-Disposition: inline
In-Reply-To: 
 <CAA-aLv4dFttCAfjc8PEx4RSoUegOwP+GTx7wiCSBdOTk3cLrTg@mail.gmail.com>
 <CA+TgmoZzHqZEVsPQUCH0JY+9MSBdAmLnSNsmdzwKSPfSLWG5Bg@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org


--RJnWrOMAazItjkl+
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

* Robert Haas (robertmhaas@gmail.com) wrote:
> On Thu, Sep 1, 2016 at 12:04 PM, Stephen Frost <sfrost@snowman.net> wrote:
> > As outlined in the commit message, this adds support for restrictive RLS
> > policies.  We've had this in the backend since 9.5, but they were only
> > available via hooks and therefore extensions.  This adds support for
> > them to be configured through regular DDL commands.  These policies are,
> > essentially "AND"d instead of "OR"d.
> >
> > Includes updates to the catalog, grammer, psql, pg_dump, and regression
> > tests.  Documentation will be added soon, but until then, would be great
> > to get feedback on the grammer, catalog and code changes.
>=20
> I don't like CREATE RESTRICT POLICY much.  It's not very good grammar,
> for one thing.  I think putting the word RESTRICT, or maybe AS
> RESTRICT, somewhere later in the command would be better.

I had been notionally thinking RESTRICTIVE, but ended up just using
RESTRICT since it was already an unreserved keyword.  Of course, that's
not a good reason.

> I also think that it is very strange to have the grammar keyword be
> "restrict" but the internal flag be called "permissive".  It would be
> better to have the sense of those flags match.

Permissive is the default and should just be added to the grammar, so
users can be explicit, if they wish to.

* Thom Brown (thom@linux.com) wrote:
> On 1 September 2016 at 10:02, Robert Haas <robertmhaas@gmail.com> wrote:
> > I don't like CREATE RESTRICT POLICY much.  It's not very good grammar,
> > for one thing.  I think putting the word RESTRICT, or maybe AS
> > RESTRICT, somewhere later in the command would be better.
> >
> > I also think that it is very strange to have the grammar keyword be
> > "restrict" but the internal flag be called "permissive".  It would be
> > better to have the sense of those flags match.
> >
> > (This is not intended as a full review, just a quick comment.)
>=20
> I had proposed this sort of functionality a couple years back:
> https://www.depesz.com/2014/10/02/waiting-for-9-5-row-level-security-poli=
cies-rls/#comment-187800
>=20
> And I suggested CREATE RESTRICTIVE POLICY, but looking back at that,
> perhaps you're right, and it would be better to add it later in the
> command.

Ah, I had recalled seeing something along those lines somewhere, but
didn't know where, thanks.

Based on Robert's suggestion and using Thom's verbiage, I've tested this
out:

CREATE POLICY pol ON tab AS [PERMISSIVE|RESTRICTIVE] ...

and it appears to work fine with the grammar, etc.

Unless there's other thoughts on this, I'll update the patch to reflect
this grammar in a couple days.

Thanks!

Stephen

--RJnWrOMAazItjkl+
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature

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

iQIcBAEBCgAGBQJXzDc5AAoJEO1sijiDR2RVGscP/1jIXjHGcjp+JFZbOyaGOrtr
Nccl6Hzzauf77uXef3odqDXHDCdA0nXkohKTNchGq49fAaBeVOYCVOPfOsk0y6Px
LhwNVU5Azmxafe7QRPTudsr3dlQDXMAl/E+cy3rt2SxN2J+ytNR23AR2Bk21Xsin
dLQKqX1YN0Tt1xZi52+7eyvT0WcXLSpN6yU0fmC3nKk7maZhx9PnAeAhVMYT5Ixo
5cNvVCUx3g58Ep97Ps/PkXh1Ub/j2zOlusvBaHMW4aV5c/EfhPshr2yBtW0I84Kp
ZWabfigxUejNBqyjC9FDUB9K+dbsELOBIHHGXKhXSKnnRofBw6PpcAA4e3LGixyp
JVwXUyQleJ9+QMXPC7bTUIkTqCZUS2zTmmEnMGXCUlJutQrlqbxKPHwtaDweR/zz
uJiVsj5zui//doEt+zEQKwnssV0N0pn4klbnU2utBB38HRJxqtLeFghbRmFkofrT
0fp10t8O/kgfxf3cszCxMODSm1HZWUTBELmS21CANuZ+RgsOnlvMJPDp4aeVzcG8
wXjaUGRIufuiLUyXfH+seSmjvAKpAdSivXlUMvN7s3QH7m1x9+bbzcNCFBcyIrq+
FSHNeBoBSN20Sx8/ZJjl/LFxC9kfdhUfi1RxdmPxBvwN6Z/X7y6fANS/g7/ONZN/
KWy4Vr5LnskiFxmiOD1F
=aEzx
-----END PGP SIGNATURE-----

--RJnWrOMAazItjkl+--