2013/2/3 Kevin Grittner <kgrittn@ymail.com>:
> I'm hoping that someone familiar with sepgsql can review this> portion of the materialized view patch and comment on
whetherit is
> the best approach for dealing with the integration of these two
> features. Basically, the patch as it stands treats a materialized
> view as a table for purposes of sepgsql labels. I initially
> invented new lables, but Robert suggested that this would make
> materialized views unusable in an SE environment until the
> corresponding labels were added at the OS level. It seems sane to
> me because a materialized view exists on disk the same as a table,
> but is populated differently -- from a view-like rule.
>
> The portion of the patch which affects the contrib/sepgsql/ tree is
> attached.
>
Hi Kevin,
Sorry, I have not been involved this discussion.
I briefly checked your patch. Indeed, it performs like a table, even though
it is named materialized-view.
Probably, we have two standpoints.
First, materialized-view shall have a security label corresponding to table,
and related checks handle references to materialized-views as if user
references regular-tables. This is an idea.
I briefly checked your latest patch. ExecRefreshMatView is a unique entry
point to update a particular materialized-view, and REFRESH MATERIALIZED
VIEW command is only way to kick this function. It also checks permissions to
reference underlying tables. So, it means update of materialized-view is a stuff
like writing a table with contents read from other tables by a particular users.
However, I'm worried whether this design continues forever, or not.
IIRC, you have a plan to refresh materialized-view asynchronously using
background worker stuff, don't you? Once we support an internal stuff (thus,
it can bypass valid security checks) to write out confidential contents into
unconfidential zone, it does not make sense to keep data confidentiality.
So, I'd like to suggest second way; that handles a materialized-view as a view.
SELinux checks db_view:{expand} permissions and relevant permissions
towards underlying tables. I don't think it is hard to implement because
relation->rd_rules holds Query tree to reference underlying tables.
Can you wait for a week? I'll adjust contrib/sepgsql portion to fit
materialized-
view with matter of existing view.
Thanks,
--
KaiGai Kohei <kaigai@kaigai.gr.jp>
