2013/2/7 Kevin Grittner <kgri...@ymail.com>: > Kohei KaiGai <kai...@kaigai.gr.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 yet.
> 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. Thanks, -- KaiGai Kohei <kai...@kaigai.gr.jp> -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
