Skip site navigation (1) Skip section navigation (2)

Re: sepgsql and materialized views

From: Kohei KaiGai <kaigai(at)kaigai(dot)gr(dot)jp>
To: Kevin Grittner <kgrittn(at)ymail(dot)com>
Cc: "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: sepgsql and materialized views
Date: 2013-02-08 13:51:40
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
2013/2/7 Kevin Grittner <kgrittn(at)ymail(dot)com>:
> Kohei KaiGai <kaigai(at)kaigai(dot)gr(dot)jp> wrote:
>> So, I'd like to review two options.
>> 1) we uses db_table object class for materialized-views for
>> a while, until selinux-side become ready. Probably, v9.3 will
>> use db_table class then switched at v9.4.
>> 2) we uses db_materialized_view object class from the
>> begining, but its permission checks are ignored because
>> installed security policy does not support this class yet.
>> My preference is 2), even though we cannot apply label
>> based permission checks until selinux support it, because
>> 1) makes troubles when selinux-side become ready to
>> support new db_materialized_view class. Even though
>> policy support MV class, working v9.3 will ignore the policy.
>> Let me ask selinux folks about this topic also.
> To make sure I understand, the current patch is consistent with
> option 1?
I believe so, even though I didn't take deep and detailed investigation

>  It sounds like I have code from a prior version of the
> patch pretty close to what you describe for option 2, so that can
> be put back in place if you confirm that as the preferred option.
As above, I'd like to suggest the option 2.
Could you once remove the updates related to contrib/sepgsql?
I'll have a discussion about new materialized_view object class
on selinux list soon, then I'll submit a patch towards contrib/sepgsql
according to the consensus here.

> From what you describe, it sounds like the only thing it doesn't
> have is a new hook for REFRESH, but that doesn't sound like it
> would take that much to implement.
I think all we need to give extensions a chance to check permission
on REFRESH timing is a hook that informs which materialized-view
shall be refreshed. Probably, OAT_MATERIALIZED_VIEW_RERESH
event with its oid on object_access_hook is sufficient.

KaiGai Kohei <kaigai(at)kaigai(dot)gr(dot)jp>

In response to


pgsql-hackers by date

Next:From: Andrew DunstanDate: 2013-02-08 14:15:59
Subject: Re: JSON NULLs
Previous:From: Peter EisentrautDate: 2013-02-08 11:47:22
Subject: Re: [PATCH] Add Makefile dep in bin/scripts for libpgport

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group