Re: Add support for restrictive RLS policies

From: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
To: Stephen Frost <sfrost(at)snowman(dot)net>
Cc: Jeevan Chalke <jeevan(dot)chalke(at)enterprisedb(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Thom Brown <thom(at)linux(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Add support for restrictive RLS policies
Date: 2016-09-26 20:43:31
Message-ID: 20160926204331.GA178854@alvherre.pgsql
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Stephen Frost wrote:

> * Alvaro Herrera (alvherre(at)2ndquadrant(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Thomas Munro 2016-09-26 22:55:07 Re: VACUUM's ancillary tasks
Previous Message Jeff Janes 2016-09-26 20:23:03 Re: Cache Hash Index meta page.