From: | Thom Brown <thom(at)linux(dot)com> |
---|---|
To: | Stephen Frost <sfrost(at)snowman(dot)net> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, "Brightwell, Adam" <adam(dot)brightwell(at)crunchydatasolutions(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com>, Craig Ringer <craig(at)2ndquadrant(dot)com>, Yeb Havinga <yeb(dot)havinga(at)portavita(dot)nl> |
Subject: | Re: RLS Design |
Date: | 2014-09-25 13:42:04 |
Message-ID: | CAA-aLv6HuzSuYSceM0k9D3iOzod7GQYnCyXWMv6XUMVkS3idOg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 19 September 2014 17:54, Stephen Frost <sfrost(at)snowman(dot)net> wrote:
>
> Thom,
>
> * Thom Brown (thom(at)linux(dot)com) wrote:
> > On 19 September 2014 17:32, Stephen Frost <sfrost(at)snowman(dot)net> wrote:
> > > * Thom Brown (thom(at)linux(dot)com) wrote:
> > > > On 14 September 2014 16:38, Stephen Frost <sfrost(at)snowman(dot)net> wrote:
> > > > # create policy visible_colours on colours for all to joe using (visible
> > > =
> > > > true);
> > > > CREATE POLICY
> > > [...]
> > > > > insert into colours (name, visible) values ('transparent',false);
> > > > ERROR: new row violates WITH CHECK OPTION for "colours"
> > > > DETAIL: Failing row contains (7, transparent, f).
> > > >
> > > > > select * from pg_policies ;
> > > > policyname | tablename | roles | cmd | qual |
> > > with_check
> > > >
> > > -----------------+-----------+-------+-----+------------------+------------
> > > > visible_colours | colours | {joe} | ALL | (visible = true) |
> > > > (1 row)
> > > >
> > > > There was no WITH CHECK OPTION.
> > >
> > > As I hope is clear if you look at the documentation- if the WITH CHECK
> > > clause is omitted, then the USING clause is used for both filtering and
> > > checking new records, otherwise you'd be able to add records which
> > > aren't visible to you.
> >
> > I can see that now, although I do find the error message somewhat
> > confusing. Firstly, it looks like "OPTION" is part of the parameter name,
> > which it isn't.
>
> Hmm, the notion of 'with check option' is from the SQL standard, which
> is why I felt the error message was appropriate as-is..
>
> > Also, I seem to get an error message with the following:
> >
> > # create policy nice_colours ON colours for all to joe using (visible =
> > true) with check (name in ('blue','green','yellow'));
> > CREATE POLICY
> >
> > \c - joe
> >
> > > insert into colours (name, visible) values ('blue',false);
> > ERROR: function with OID 0 does not exist
>
> Now *that* one is interesting and I'll definitely go take a look at it.
> We added quite a few regression tests to try and make sure these things
> work.
>
> > And if this did work, but I only violated the USING clause, would this
> > still say the WITH CHECK clause was the cause?
>
> WITH CHECK applies for INSERT and UPDATE for the new records going into
> the table. You can't actually violate the USING clause for an INSERT
> as USING is for filtering records, not checking that records being added
> to the table are valid.
>
> To try and clarify- by explicitly setting both USING and WITH CHECK, you
> *are* able to INSERT records which are not visible to you. We felt that
> was an important capability to support.
I find it a bit of a limitation that I can't specify both INSERT and
UPDATE for a policy. I'd want to be able to specify something like
this:
CREATE POLICY no_greys_allowed
ON colours
FOR INSERT, UPDATE
WITH CHECK (name NOT IN ('grey','gray'));
I would expect this to be rather common to prevent certain values
making their way into a table. Instead I'd have to create 2 policies
as it stands.
In order to debug issues with accessing table data, perhaps it would
be useful to output the name of the policy that was violated. If a
table had 20 policies on, it could become time-consuming to debug.
I keep getting tripped up by overlapping policies. On the one hand, I
created a policy to ensure rows being added or selected have a
"visible" column set to true. On the other hand, I have a policy that
ensures that the name of a colour doesn't appear in a list. Policy 1
is violated until policy 2 is added:
(using the table I created in a previous post on this thread...)
# create policy must_be_visible ON colours for all to joe using
(visible = true) with check (visible = true);
CREATE POLICY
\c - joe
> insert into colours (name, visible) values ('pink',false);
ERROR: new row violates WITH CHECK OPTION for "colours"
DETAIL: Failing row contains (28, pink, f).
\c - thom
# create policy no_greys_allowed on colours for insert with check
(name not in ('grey','gray'));
CREATE POLICY
\c - joe
# insert into colours (name, visible) values ('pink',false);
INSERT 0 1
I expected this to still trigger an error due to the first policy. Am
I to infer from this that the policy model is permissive rather than
restrictive?
I've also attached a few corrections for the docs.
Thom
Attachment | Content-Type | Size |
---|---|---|
policy_doc_corrections.diff | text/plain | 2.5 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Simon Riggs | 2014-09-25 13:43:14 | Re: a fast bloat measurement tool (was Re: Measuring relation free space) |
Previous Message | Andres Freund | 2014-09-25 13:34:59 | Inefficient barriers on solaris with sun cc |