Stephen Frost wrote:
> Will look into it and try to provide an update soon.
>
> Any further thoughts or suggestions would be appreciated.
My recollection is that there were two ways that were being
considered, and I posted a patch for each of them, but the security
community couldn't reach a con
> * Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
> > Kohei KaiGai wrote:
> > > Unfortunately, I could not get consensus of design on selinux policy side.
> > > Even though my opinion is to add individual security class for
> > > materialized
> > > view to implement refresh permission, other pe
* Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
> Kohei KaiGai wrote:
> > Unfortunately, I could not get consensus of design on selinux policy side.
> > Even though my opinion is to add individual security class for materialized
> > view to implement refresh permission, other people has differen
Kohei KaiGai wrote:
> Unfortunately, I could not get consensus of design on selinux policy side.
> Even though my opinion is to add individual security class for materialized
> view to implement refresh permission, other people has different opinion.
> So, I don't want it shall be a blocker of v9.3
Tom Lane wrote:
> Noah Misch writes:
>> On Fri, Feb 08, 2013 at 02:51:40PM +0100, Kohei KaiGai wrote:
>>> 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.
>
>> Has this p
Unfortunately, I could not get consensus of design on selinux policy side.
Even though my opinion is to add individual security class for materialized
view to implement refresh permission, other people has different opinion.
So, I don't want it shall be a blocker of v9.3 to avoid waste of time.
Als
Noah Misch writes:
> On Fri, Feb 08, 2013 at 02:51:40PM +0100, Kohei KaiGai wrote:
>> 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.
> Has this progressed?
> Should we c
On Fri, Feb 08, 2013 at 02:51:40PM +0100, Kohei KaiGai wrote:
> 2013/2/7 Kevin Grittner :
> > Kohei KaiGai 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
> >> us
Kohei KaiGai wrote:
> I'll adjust contrib/sepgsql portion to fit materialized-view with
> matter of existing view.
OK. In case it is of any use to you as a starting point, attached
is what I originally had, which seems to be similar to what you
describe as your preference. I'll revert everythi
2013/2/7 Kevin Grittner :
> Kohei KaiGai 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 o
Kohei KaiGai 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, b
Thanks for your introduction. It made me almost clear.
>From selinux perspective, it does not switch user's privilege even when
query scans underlying tables because it has no ownership concept.
The current implementation does not make a problem because all the
MV refresh shall be done in a partic
Kohei KaiGai wrote:
> Let me confirm a significant point. Do you never plan a feature
> that allows to update/refresh materialized-views out of user
> session?
Currently only the owner of the MV or a database superuser can
refresh it, and the refresh is run with the permissions of the MV
owner.
2013/2/4 Kevin Grittner :
> Kohei KaiGai wrote:
>> 2013/2/3 Kevin Grittner :
>>> I'm hoping that someone familiar with sepgsql can review this
>>> portion of the materialized view patch and comment on whether it is
>>> the best approach for dealing with the integration of these two
>>> features.
Kohei KaiGai wrote:
> 2013/2/3 Kevin Grittner :
>> I'm hoping that someone familiar with sepgsql can review this
>> portion of the materialized view patch and comment on whether it is
>> the best approach for dealing with the integration of these two
>> features. Basically, the patch as it stands
2013/2/3 Kevin Grittner :
> I'm hoping that someone familiar with sepgsql can review this> portion of the
> materialized view patch and comment on whether it is
> the best approach for dealing with the integration of these two
> features. Basically, the patch as it stands treats a materialized
>
I'm hoping that someone familiar with sepgsql can review this
portion of the materialized view patch and comment on whether it 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 sepgsq
17 matches
Mail list logo
