Re: WIP patch (v2) for updatable security barrier views

From: Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com>
To: KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(dot)com>
Cc: Craig Ringer <craig(at)2ndquadrant(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, Kohei KaiGai <kaigai(at)kaigai(dot)gr(dot)jp>, Robert Haas <robertmhaas(at)gmail(dot)com>, Simon Riggs <simon(at)2ndquadrant(dot)com>
Subject: Re: WIP patch (v2) for updatable security barrier views
Date: 2014-01-23 10:06:25
Message-ID: CAEZATCVAqJV5WTjLmyObP21n+CzhbEx2AOzH4e6qmTcueVDjdQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 21 January 2014 09:18, Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com> wrote:
> Yes, please review the patch from 09-Jan
> (http://www.postgresql.org/message-id/CAEZATCUiKxOg=vOOvjA2S6G-sixzzxg18ToTggP8zOBq6QnQHQ@mail.gmail.com)
>

After further testing I found a bug --- it involves having a security
barrier view on top of a base relation that has a rule that rewrites
the query to have a different result relation, and possibly also a
different command type, so that the securityQuals are no longer on the
result relation, which is a code path not previously tested and the
rowmark handling was wrong. That's probably a pretty obscure case in
the context of security barrier views, but that code path would be
used much more commonly if RLS were built on top of this. Fortunately
the fix is trivial --- updated patch attached.

Regards,
Dean

Attachment Content-Type Size
updatable-sb-views.patch text/x-diff 63.3 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Dean Rasheed 2014-01-23 10:25:59 Re: WIP patch (v2) for updatable security barrier views
Previous Message Steeve Lennmark 2014-01-23 10:01:55 Re: [PATCH] Relocation of tablespaces in pg_basebackup