Thread: Will there ever be support for Row Level Security on Materialized Views?

On 28 August 2018 at 09:58, Ken Tanzer <ken.tanzer@gmail.com> wrote:
> On Tue, Aug 14, 2018 at 5:24 PM Ken Tanzer <ken.tanzer@gmail.com> wrote:
>> Basically, I'm wondering whether materialized views are likely to ever support row-level security.
>
> Hi.  Just wanted to follow up on my own email and see if anyone could answer this.

You might think there's some master project-wide list of things that
are to implement that we all work from, but there's not. There is a
todo list [1] that might serve as some sort of guide for a new person
who wishes to contribute something, who's looking for inspiration as
to what to contribute, but I don't think that list ever goes much
beyond that.

New features normally appear for one of two reasons:

1) A developer gets inspired to make something happen; or
2) Someone pays a developer to make something happen.

So I guess in this case either 1 or 2 has not happened, or they have
but the correct people have either not seen your email or they just
simply don't want to answer.

If you're desperate for the feature, I'd recommend looking into the
possibility of going with 1 or 2.

[1] https://wiki.postgresql.org/wiki/Todo

On 28 August 2018 at 11:06, Ken Tanzer <ken.tanzer@gmail.com> wrote:
> Or perhaps they "simply don't want to answer." Well I wondered about that too, since the last person who asked about
thisdidn't get a response either.  Is it a particularly stupid question?  Is there some history that makes it a touchy
subject? Or is it just the Bermuda Triangle of this mailing list? :) 

I can't imagine why it would be a touchy subject.  Generally, if
you're working on a feature its best not to keep it a secret as if
someone else does the same, then you end up with redundant work being
done.

If I had to guess what's going on here then I'd say that nobody has
been sufficiently motivated to work on this yet. If that's the case,
everyone who reads your email is not the person working on this
feature, so can't answer your question.   I just answered to suggest
the reasons why you might not be getting an answer.


--
 David Rowley                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services

On 2018-Aug-27, Ken Tanzer wrote:

>    - Is there any reason there is no RLS / MV support now?

Nobody worked on it yet.

>    - Are there any reason fundamental reasons why PG couldn't support RLS
>    for MVs?

Doesn't look like it.

>    - Is it just a matter of nobody has done it yet?

Yeah.

>    - Is there other development work that would need to happen before this
>    could be implemented?

Doesn't look like it.

>    - In the scheme of things, is it a lot of work or not so much?

Probably not much.

>    - Has there been any discussion of implementing this feature, and if so
>    is there a link to it?

Not that I remember.

-- 
Álvaro Herrera                https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

On 28 August 2018 at 01:49, Alvaro Herrera <alvherre@2ndquadrant.com> wrote:
> On 2018-Aug-27, Ken Tanzer wrote:
>>    - In the scheme of things, is it a lot of work or not so much?
>
> Probably not much.
>

Yeah, it doesn't seem like it would be particularly difficult, but it
would probably still be a reasonable amount of work to go round
finding all the places in code that would need updating. I.e., I think
it would be more mechanical work, than anything fundamentally
challenging.

On the face of it, it seems like it might be a reasonable thing to
support, but I wonder, is this really just syntactic sugar for
creating a security barrier view on top of the materialized view?

When RLS was originally implemented, that same question was asked for
tables, but the answer was "no" because RLS on a table gives you
fine-grained (row-level) control over what data in the table can be
modified as well as read, which a SB view doesn't give you. But for a
MV view, that's not a consideration, so what would RLS on a MV
actually give you?

Regards,
Dean

Greetings,

* Dean Rasheed (dean.a.rasheed@gmail.com) wrote:
> On 28 August 2018 at 01:49, Alvaro Herrera <alvherre@2ndquadrant.com> wrote:
> > On 2018-Aug-27, Ken Tanzer wrote:
> >>    - In the scheme of things, is it a lot of work or not so much?
> >
> > Probably not much.
>
> Yeah, it doesn't seem like it would be particularly difficult, but it
> would probably still be a reasonable amount of work to go round
> finding all the places in code that would need updating. I.e., I think
> it would be more mechanical work, than anything fundamentally
> challenging.
>
> On the face of it, it seems like it might be a reasonable thing to
> support, but I wonder, is this really just syntactic sugar for
> creating a security barrier view on top of the materialized view?
>
> When RLS was originally implemented, that same question was asked for
> tables, but the answer was "no" because RLS on a table gives you
> fine-grained (row-level) control over what data in the table can be
> modified as well as read, which a SB view doesn't give you. But for a
> MV view, that's not a consideration, so what would RLS on a MV
> actually give you?

I see value in being able to have a consistent set of policies which
are applied across tables, views, matviews, etc.  Also, with simple
updateable views, updates can be done, so there's also that to consider.
Ultimately, I do think it'd be good to have RLS support for views, mat
views, and foreign tables.

Thanks!

Stephen

On 08/27/2018 07:38 PM, Ken Tanzer wrote:
> On Mon, Aug 27, 2018 at 4:23 PM David Rowley
> <david.rowley@2ndquadrant.com <mailto:david.rowley@2ndquadrant.com>> wrote:
>
>> If I had to guess what's going on here then I'd say that nobody has
>> been sufficiently motivated to work on this yet. If that's the case,
>> everyone who reads your email is not the person working on this
>> feature, so can't answer your question.   I just answered to suggest
>> the reasons why you might not be getting an answer.
>
> Thanks, that makes sense, and I appreciate that.

Since no one else mentioned it, I would add that questions about
development of Postgres features might be better directed at the hackers
list rather than here.

Joe

--
Crunchy Data - http://crunchydata.com
PostgreSQL Support for Secure Enterprises
Consulting, Training, & Open Source Development