On 15 November 2012 21:07, Kohei KaiGai wrote:
> The attached patch is a revised version of row-level security
> feature.
I've got time to review this patch, so I've added myself as a CF reviewer.
Definitely looks very interesting, well done for getting it this far along.
--
Simon Riggs
David Fetter escribió:
> On Mon, Dec 03, 2012 at 03:41:47PM +, Simon Riggs wrote:
> > On 3 December 2012 15:36, Kohei KaiGai wrote:
> > > 2012/12/3 David Fetter :
> > >> On Sun, Nov 25, 2012 at 03:20:28PM +0100, Kohei KaiGai wrote:
> > >>> > However, UPDATE / DELETE support is not perfect righ
On Mon, Dec 03, 2012 at 03:41:47PM +, Simon Riggs wrote:
> On 3 December 2012 15:36, Kohei KaiGai wrote:
> > 2012/12/3 David Fetter :
> >> On Sun, Nov 25, 2012 at 03:20:28PM +0100, Kohei KaiGai wrote:
> >>> > However, UPDATE / DELETE support is not perfect right now.
> >>> > In case when we tr
On 3 December 2012 15:36, Kohei KaiGai wrote:
> 2012/12/3 David Fetter :
>> On Sun, Nov 25, 2012 at 03:20:28PM +0100, Kohei KaiGai wrote:
>>> > However, UPDATE / DELETE support is not perfect right now.
>>> > In case when we try to update / delete a table with inherited
>>> > children and RETURNIN
2012/12/3 David Fetter :
> On Sun, Nov 25, 2012 at 03:20:28PM +0100, Kohei KaiGai wrote:
>> > However, UPDATE / DELETE support is not perfect right now.
>> > In case when we try to update / delete a table with inherited
>> > children and RETURNING clause was added, is loses right
>> > references to
On Sun, Nov 25, 2012 at 03:20:28PM +0100, Kohei KaiGai wrote:
> > However, UPDATE / DELETE support is not perfect right now.
> > In case when we try to update / delete a table with inherited
> > children and RETURNING clause was added, is loses right
> > references to the pseudo columns, even thoug
2012/10/22 Robert Haas :
> On Thu, Oct 18, 2012 at 2:19 PM, Alvaro Herrera
> wrote:
>> Kohei KaiGai escribió:
>>> The revised patch fixes the problem that Daen pointed out.
>>
>> Robert, would you be able to give this latest version of the patch a
>> look?
>
> Yeah, sorry I've been completely side
On Mon, Oct 22, 2012 at 12:17 PM, Tom Lane wrote:
> Robert Haas writes:
>> The documentation lists several documented limitations that I would
>> like to analyze a little bit. First, it says that row-level security
>> policies are not applied on UPDATE or DELETE. That sounds downright
>> danger
Robert Haas writes:
> The documentation lists several documented limitations that I would
> like to analyze a little bit. First, it says that row-level security
> policies are not applied on UPDATE or DELETE. That sounds downright
> dangerous to me. Is there some really compelling reason we're
On Thu, Oct 18, 2012 at 2:19 PM, Alvaro Herrera
wrote:
> Kohei KaiGai escribió:
>> The revised patch fixes the problem that Daen pointed out.
>
> Robert, would you be able to give this latest version of the patch a
> look?
Yeah, sorry I've been completely sidelined this CommitFest. It's been
a cr
On Fri, October 19, 2012 11:00, Kohei KaiGai wrote:
> I confirmed I could apply the latest patch cleanly.
>
FWIW, I spent a few sessions (amounting to a few hours) trying to break, or get
past SET ROW LEVEL
SECURITY and have not yet succeeded. So far so good.
(I haven't looked at code)
Erik Ri
2012/10/18 Alvaro Herrera :
> Kohei KaiGai escribió:
>> The revised patch fixes the problem that Daen pointed out.
>
> Robert, would you be able to give this latest version of the patch a
> look?
>
> (KaiGai, does it still apply cleanly? If not, please submit a rebased
> version.)
>
I confirmed I c
Kohei KaiGai escribió:
> The revised patch fixes the problem that Daen pointed out.
Robert, would you be able to give this latest version of the patch a
look?
(KaiGai, does it still apply cleanly? If not, please submit a rebased
version.)
--
Álvaro Herrerahttp://www.2ndQuadrant.
2012/10/8 Dean Rasheed :
> On 8 October 2012 15:57, Kohei KaiGai wrote:
>> The attached patch is a refreshed version towards the latest master branch,
>> to fix up patch conflicts.
>> Here is no other difference from the previous revision.
>>
>> Thanks,
>>
>
> I had another look at this over the w
On 8 October 2012 15:57, Kohei KaiGai wrote:
> The attached patch is a refreshed version towards the latest master branch,
> to fix up patch conflicts.
> Here is no other difference from the previous revision.
>
> Thanks,
>
I had another look at this over the weekend and I found couple of
additio
On 17 July 2012 05:02, Kohei KaiGai wrote:
> 2012/7/17 Robert Haas :
>> On Sun, Jul 15, 2012 at 5:52 AM, Kohei KaiGai wrote:
>>> The attached patch is a revised version of row-level security feature.
>>> ...
>>> According to the Robert's comment, I revised the place to inject
>>> applyRowLevelSec
2012/7/17 Robert Haas :
> On Sun, Jul 15, 2012 at 5:52 AM, Kohei KaiGai wrote:
>> The attached patch is a revised version of row-level security feature.
>>
>> I added a feature to invalidate plan cache if user-id was switched
>> between planner and optimizer. It enabled to generate more optimized
On Sun, Jul 15, 2012 at 5:52 AM, Kohei KaiGai wrote:
> The attached patch is a revised version of row-level security feature.
>
> I added a feature to invalidate plan cache if user-id was switched
> between planner and optimizer. It enabled to generate more optimized
> plan than the previous appro
2012/6/28 Tom Lane :
> Kohei KaiGai writes:
>> 2012/6/27 Florian Pflug :
>>> Hm, what happens if a SECURITY DEFINER functions returns a refcursor?
>
>> My impression is, here is no matter even if SECURITY DEFINER function
>> returns refcursor.
>
> I think Florian has a point: it *should* work, but
Florian Pflug writes:
> On Jun28, 2012, at 17:29 , Tom Lane wrote:
>> I believe it works today, because the executor only applies permissions
>> checks during query startup. So those checks are executed while still
>> within the SECURITY DEFINER context, and should behave as expected.
>> Subseque
On Jun28, 2012, at 17:29 , Tom Lane wrote:
> Kohei KaiGai writes:
>> 2012/6/27 Florian Pflug :
>>> Hm, what happens if a SECURITY DEFINER functions returns a refcursor?
>
>> My impression is, here is no matter even if SECURITY DEFINER function
>> returns refcursor.
>
> I think Florian has a poin
Kohei KaiGai writes:
> 2012/6/27 Florian Pflug :
>> Hm, what happens if a SECURITY DEFINER functions returns a refcursor?
> My impression is, here is no matter even if SECURITY DEFINER function
> returns refcursor.
I think Florian has a point: it *should* work, but *will* it?
I believe it works
2012/6/27 Florian Pflug :
> On Jun27, 2012, at 15:07 , Kohei KaiGai wrote:
>> Probably, PlannedStmt->invalItems allows to handle invalidation of
>> plan-cache without big code changes. I'll try to put a flag of user-id
>> to track the query plan with RLS assumed, or InvalidOid if no RLS
>> was appl
On Jun27, 2012, at 15:07 , Kohei KaiGai wrote:
> Probably, PlannedStmt->invalItems allows to handle invalidation of
> plan-cache without big code changes. I'll try to put a flag of user-id
> to track the query plan with RLS assumed, or InvalidOid if no RLS
> was applied in this plan.
> I'll investi
2012/6/27 Robert Haas :
> On Wed, Jun 27, 2012 at 7:21 AM, Florian Pflug wrote:
>> On Jun27, 2012, at 07:18 , Kohei KaiGai wrote:
>>> The problem is the way to implement it.
>>> If we would have permission checks on planner stage, it cannot handle
>>> a case when user-id would be switched prior to
On Wed, Jun 27, 2012 at 7:21 AM, Florian Pflug wrote:
> On Jun27, 2012, at 07:18 , Kohei KaiGai wrote:
>> The problem is the way to implement it.
>> If we would have permission checks on planner stage, it cannot handle
>> a case when user-id would be switched prior to executor stage, thus
>> it ne
2012/6/27 Florian Pflug :
> On Jun27, 2012, at 07:18 , Kohei KaiGai wrote:
>> The problem is the way to implement it.
>> If we would have permission checks on planner stage, it cannot handle
>> a case when user-id would be switched prior to executor stage, thus
>> it needs something remedy to handl
On Jun27, 2012, at 07:18 , Kohei KaiGai wrote:
> The problem is the way to implement it.
> If we would have permission checks on planner stage, it cannot handle
> a case when user-id would be switched prior to executor stage, thus
> it needs something remedy to handle the scenario correctly.
> Inst
2012/6/26 Tom Lane :
> Kohei KaiGai writes:
>> 2012/6/26 Robert Haas :
>>> I think you're missing the point. Everyone who has commented on this
>>> issue is in favor of having some check that causes the RLS predicate
>>> *not to get added in the first place*.
>
>> Here is a simple idea to avoid t
Kohei KaiGai writes:
> 2012/6/26 Robert Haas :
>> I think you're missing the point. Everyone who has commented on this
>> issue is in favor of having some check that causes the RLS predicate
>> *not to get added in the first place*.
> Here is a simple idea to avoid the second problematic scenari
2012/6/26 Robert Haas :
>> Of course, here is some limitations, to keep the patch size reasonable
>> level to review.
>> - The permission to bypass RLS policy was under discussion.
>> If and when we should provide a special permission to bypass RLS
>> policy, the "OR has_superuser_privilege()" sh
On Thu, Jun 14, 2012 at 11:43 AM, Kohei KaiGai wrote:
> In the previous discussion, we planned to add a syntax option to
> clarify the command type to fire the RLS policy, such as FOR UPDATE.
> But current my opinion is, it is not necessary. For example, we can
> reference the contents of rows bei
32 matches
Mail list logo
