On 27 March 2013 10:57, Kohei KaiGai wrote:
> 2013/3/25 Simon Riggs :
>> On 19 March 2013 15:08, Kohei KaiGai wrote:
>>
>>> It is much helpful if someone give me comments around these
>>> arguable portions from the standpoint with fresh eyes.
>>
>> My feeling at this point is that I don't think I
I moved Row Level Security patch to the 2013-Next commitfest.
2013/3/27 Kohei KaiGai :
> 2013/3/25 Simon Riggs :
>> On 19 March 2013 15:08, Kohei KaiGai wrote:
>>
>>> It is much helpful if someone give me comments around these
>>> arguable portions from the standpoint with fresh eyes.
>>
>> My fe
2013/3/25 Simon Riggs :
> On 19 March 2013 15:08, Kohei KaiGai wrote:
>
>> It is much helpful if someone give me comments around these
>> arguable portions from the standpoint with fresh eyes.
>
> My feeling at this point is that I don't think I should commit this
> and related patches without mor
On 19 March 2013 15:08, Kohei KaiGai wrote:
> It is much helpful if someone give me comments around these
> arguable portions from the standpoint with fresh eyes.
My feeling at this point is that I don't think I should commit this
and related patches without more work.
I certainly have time and
On 01/16/2013 06:28 AM, Kohei KaiGai wrote:
> The attached patch is row-security v9.
Has anyone had a chance to check this out? It's seen a lot of work over
a long time and looks really valuable if it's solid enough.
Kohei KaiGai, is there any chance you can go through Simon's review and
offer an
KaiGai,
* Kohei KaiGai (kai...@kaigai.gr.jp) wrote:
> IMO, only "parser" should accept command types except for ALL but
> raise an error something like "it is not supported yet" to protect from
> syntax conflicts.
Right, I agree with this.
> Right now, I plan to submit a revised patch with the s
On Wed, Jan 02, 2013 at 05:31:42PM +, Simon Riggs wrote:
> On 2 January 2013 17:19, David Fetter wrote:
>
> > Would COPY be covered separately? How about TRUNCATE?
>
> COPY == INSERT
Makes sense. The reason I mentioned it is that COPY is supposed to be
a very fast bulk loading process, wh
On 2 January 2013 17:19, David Fetter wrote:
> Would COPY be covered separately? How about TRUNCATE?
COPY == INSERT
TRUNCATE isn't covered at all since it doesn't look at rows. It has a
separate privilege that can be granted to those that need it.
> Also, is there any way to apply this to the
On Wed, Jan 02, 2013 at 05:35:13PM +0100, Kohei KaiGai wrote:
> 2012/12/31 Simon Riggs :
> > On 23 December 2012 18:49, Simon Riggs wrote:
> >
> >> Anyway, hope you can make call on 28th so we can discuss this and
> >> agree a way forwards you're happy with.
> >
> > Stephen, KaiGai and myself met
2012/12/31 Simon Riggs :
> On 23 December 2012 18:49, Simon Riggs wrote:
>
>> Anyway, hope you can make call on 28th so we can discuss this and
>> agree a way forwards you're happy with.
>
> Stephen, KaiGai and myself met by phone on 28th to discuss.
>
> 1. The actual default is not that important
On 23 December 2012 18:49, Simon Riggs wrote:
> Anyway, hope you can make call on 28th so we can discuss this and
> agree a way forwards you're happy with.
Stephen, KaiGai and myself met by phone on 28th to discuss.
1. The actual default is not that important to any of us. We could go
either wa
On 23 December 2012 19:16, Tom Lane wrote:
> Simon Riggs writes:
>> On 21 December 2012 16:51, Kevin Grittner wrote:
>>> If none, and this is strictly an optimization, what are the benchmarks
>>> showing?
>
>> AFAIK its well known that a check constraint is much faster than a
>> trigger.
>
> I d
Simon Riggs writes:
> On 21 December 2012 16:51, Kevin Grittner wrote:
>> If none, and this is strictly an optimization, what are the benchmarks
>> showing?
> AFAIK its well known that a check constraint is much faster than a
> trigger.
I don't believe that that's "well known" at all, at least
On 21 December 2012 16:51, Kevin Grittner wrote:
>> It would be easy enough to include read/write variable clauses by
>> using a function similar to TG_OP for triggers, e.g. StatementType.
>> That would make the security clause that applied only to reads into
>> something like this (StatementType
2012/12/22 Kevin Grittner :
> Kohei KaiGai wrote:
>
>> RLS entry of wiki has not been updated for long time, I'll try to
>> update the entry for high-level design in a couple of days.
>
> Thanks, I think that is essential for a productive discussion of
> the issue.
>
I tried to update http://wiki.p
On 22 December 2012 20:13, Kevin Grittner wrote:
> I apologize again for coming in so late with strong opinions, but I
> thought I knew what "row level security" meant, and it was just a
> question of how to do it, but I can't reconcile what I thought the
> feature was about with the patch I'm se
Kohei KaiGai wrote:
> RLS entry of wiki has not been updated for long time, I'll try to
> update the entry for high-level design in a couple of days.
Thanks, I think that is essential for a productive discussion of
the issue.
For me, it would help tremendously if you could provide a very
short s
2012/12/22 Simon Riggs :
> On 21 December 2012 22:01, Stephen Frost wrote:
>
>>> On the other hand, we are standing next to the consensus about
>>> reader-side; a unique row-security policy (so, first version does not
>>> support per-command policy) shall be checked on table scanning
>>> on select
2012/12/21 Stephen Frost :
>> It seems to me we need some more discussion about design and
>> implementation on row-security checks of writer-side, to reach our
>> consensus.
>
> Again, I agree with Kevin on this- there should be a wiki or similar
> which actually outlines the high-level design, sy
Simon,
* Simon Riggs (si...@2ndquadrant.com) wrote:
> Would anybody like to discuss this on a conference call on say 28th
> Dec, to see if we can agree a way forwards? I feel certain that we can
> work through any difficulties and agree a minimal subset for change.
> All comers welcome, just conta
On 21 December 2012 22:01, Stephen Frost wrote:
>> On the other hand, we are standing next to the consensus about
>> reader-side; a unique row-security policy (so, first version does not
>> support per-command policy) shall be checked on table scanning
>> on select, update or delete commands.
>
>
KaiGai, all,
* Kohei KaiGai (kai...@kaigai.gr.jp) wrote:
> 2012/12/21 Kevin Grittner :
> > Simon Riggs wrote:
> >
> >> Each table has a single security clause. The clause doesn't enforce
> >> that it must contain something that depends on role, but that is the
> >> most easily understood usage of
2012/12/21 Kevin Grittner :
> Simon Riggs wrote:
>
>> Each table has a single security clause. The clause doesn't enforce
>> that it must contain something that depends on role, but that is the
>> most easily understood usage of it. We do that to ensure that you can
>> embed the intelligence into a
Simon Riggs wrote:
> Each table has a single security clause. The clause doesn't enforce
> that it must contain something that depends on role, but that is the
> most easily understood usage of it. We do that to ensure that you can
> embed the intelligence into a function, say hasRowLevelAccess(),
On 21 December 2012 14:48, Kevin Grittner wrote:
> Kohei KaiGai wrote:
>
>>> I don't think I like ALTER TABLE as a syntax for row level
>>> security. How about using existing GRANT syntax but allowing a
>>> WHERE clause? That seems more natural to me, and it would make
>>> it easy to apply the sam
Kohei KaiGai wrote:
>> I don't think I like ALTER TABLE as a syntax for row level
>> security. How about using existing GRANT syntax but allowing a
>> WHERE clause? That seems more natural to me, and it would make
>> it easy to apply the same conditions to multiple types of
>> operations when desi
On 21 December 2012 14:19, Robert Haas wrote:
> On Fri, Dec 21, 2012 at 3:56 AM, Simon Riggs wrote:
>> It's unreasonable for people to demand a feature yet provide no
>> guidance to the person trying (hard) to provide that feature in a
>> sensible way.
>
> You've got it backwards. All the issues
On Fri, Dec 21, 2012 at 3:56 AM, Simon Riggs wrote:
> It's unreasonable for people to demand a feature yet provide no
> guidance to the person trying (hard) to provide that feature in a
> sensible way.
You've got it backwards. All the issues that are being discussed now
on this thread have been
On Thu, Dec 20, 2012 at 4:50 PM, Kevin Grittner wrote:
> I don't think I like ALTER TABLE as a syntax for row level
> security. How about using existing GRANT syntax but allowing a
> WHERE clause? That seems more natural to me, and it would make it
> easy to apply the same conditions to multiple t
On 21 December 2012 09:29, Dean Rasheed wrote:
> On 21 December 2012 08:56, Simon Riggs wrote:
>> It's unreasonable for people to demand a feature yet provide no
>> guidance to the person trying (hard) to provide that feature in a
>> sensible way. If people genuinely believe case (2) is worth pur
On 21 December 2012 08:56, Simon Riggs wrote:
> It's unreasonable for people to demand a feature yet provide no
> guidance to the person trying (hard) to provide that feature in a
> sensible way. If people genuinely believe case (2) is worth pursuing,
> additional work and input is needed so that
On 20 December 2012 19:42, Stephen Frost wrote:
> Kevin, all,
>
> * Kevin Grittner (kgri...@mail.com) wrote:
>> The more secure behavior is to allow entry of data which will not
>> be visible by the person doing the entry.
>
> wrt this- I'm inclined to agree with Kevin. It's certainly common in
>
2012/12/20 Kevin Grittner :
> Kohei KaiGai wrote:
>
>> If system ensures writer's permission is always equivalent or
>> more restrictive than reader's permission, it also eliminates the
>> problem around asymmetric row-security policy between commands.
>
> I'm not sure we're understanding each othe
On 20 December 2012 21:50, Kevin Grittner wrote:
> How about using existing GRANT syntax but allowing a
> WHERE clause?
It's a nice feature, but a completely different thing to what is being
discussed here.
Row security adds the ability to enforce a single coherent policy at
table level. It mig
Kohei KaiGai wrote:
> If system ensures writer's permission is always equivalent or
> more restrictive than reader's permission, it also eliminates the
> problem around asymmetric row-security policy between commands.
I'm not sure we're understanding each other; so far people who
favor asymmetric
2012/12/20 Robert Haas :
> On Thu, Dec 20, 2012 at 4:35 AM, Simon Riggs wrote:
>> Not sure I understand you. You suggested it was a valid use case for a
>> user to have only INSERT privilege and wish to bypass security checks.
>> I agreed and suggested it could be special-cased.
>
> That's not rea
* Robert Haas (robertmh...@gmail.com) wrote:
> > * "Applies to all commands" should not be implemented via triggers.
> > Complex, slow, unacceptable thing to force upon users. Doing that begs
> > the question of why we would have the feature at all, since we already
> > have triggers and barrier vi
2012/12/20 Stephen Frost :
> Kevin, all,
>
> * Kevin Grittner (kgri...@mail.com) wrote:
>> The more secure behavior is to allow entry of data which will not
>> be visible by the person doing the entry.
>
> wrt this- I'm inclined to agree with Kevin. It's certainly common in
> certain environments
On Thu, Dec 20, 2012 at 4:35 AM, Simon Riggs wrote:
> Not sure I understand you. You suggested it was a valid use case for a
> user to have only INSERT privilege and wish to bypass security checks.
> I agreed and suggested it could be special-cased.
That's not really what I intended to suggest.
Kevin, all,
* Kevin Grittner (kgri...@mail.com) wrote:
> The more secure behavior is to allow entry of data which will not
> be visible by the person doing the entry.
wrt this- I'm inclined to agree with Kevin. It's certainly common in
certain environments that you can write to a higher level th
On 20 December 2012 00:24, Robert Haas wrote:
> On Wed, Dec 19, 2012 at 12:54 PM, Simon Riggs wrote:
>> I can see a use case for not having security apply for users who have
>> *only* INSERT privilege. This would allow people to run bulk loads of
>> data into a table with row security. We should
On Wed, Dec 19, 2012 at 1:58 PM, Simon Riggs wrote:
> If we don't enforce rules on INSERT the user has to specifically add a
> trigger, which makes things noticeably slower. There is more
> maintenance work for the average user, less performance and more
> mistakes to make.
Well, again, only if t
On Wed, Dec 19, 2012 at 12:54 PM, Simon Riggs wrote:
> I can see a use case for not having security apply for users who have
> *only* INSERT privilege. This would allow people to run bulk loads of
> data into a table with row security. We should add that. That is not
> the common case, so with pro
On 2012-12-19 18:25, Robert Haas wrote:
On Tue, Dec 18, 2012 at 3:39 PM, Kohei KaiGai wrote:
postgres=> INSERT INTO t1 VALUES (4,'ddd');
INSERT 0 1
postgres=> INSERT INTO t1 VALUES (5,'eee');
ERROR: new row for relation "t1" violates row-secirity
DETAIL: Failing row contains (5, eee).
I've a
Simon Riggs wrote:
> Kevin Grittner wrote:
>
>> I hope we can leave the syntax for this feature open to such
>> specification, even if the initial implementation only supports
>> limiting reads.
>
> Well, I hope the opposite: that we can support simple full security by
> default, while leaving s
On 19 December 2012 20:37, Kevin Grittner wrote:
> Andres Freund wrote:
>
>> I don't think it is that simple. Allowing inserts without regard for row
>> level restrictions makes it far easier to probe for data. E.g. by
>> inserting rows and checking for unique violations.
>
> Unless you want to go
> > The more secure behavior is to allow entry of data which will not be
> > visible by the person doing the entry.
>
> I don't think it is that simple. Allowing inserts without regard for row
level
> restrictions makes it far easier to probe for data. E.g. by inserting rows
and
> checking for uni
On 19 December 2012 20:23, Kevin Grittner wrote:
> I hope we can leave the syntax for this feature open to such
> specification, even if the initial implementation only supports
> limiting reads.
Well, I hope the opposite: that we can support simple full security by
default, while leaving syntax
Andres Freund wrote:
> I don't think it is that simple. Allowing inserts without regard for row
> level restrictions makes it far easier to probe for data. E.g. by
> inserting rows and checking for unique violations.
Unless you want to go to a military-style security level system
where people at
Simon Riggs wrote:
> I've argued that row security should apply to ALL commands by default.
> Which is exactly the same default as Oracle, as well as being the
> obvious common sense understanding of "row security", which does not
> cause a POLA violation.
>
> I have no objection to an option to
On 2012-12-19 14:46:18 -0500, Kevin Grittner wrote:
> Simon Riggs wrote:
>
> > This is security, not spec compliance. By default, we need full
> > security.
>
> But you are arguing that users should not be able to make something
> secure if they, and everyone with the same permissions, could not
>
On 19 December 2012 19:46, Kevin Grittner wrote:
> But you are arguing that users should not be able to make something
> secure if they, and everyone with the same permissions, could not
> later access it.
Not exactly, no.
I've argued that row security should apply to ALL commands by default.
W
Simon Riggs wrote:
> This is security, not spec compliance. By default, we need full
> security.
But you are arguing that users should not be able to make something
secure if they, and everyone with the same permissions, could not
later access it. I thought about situations where I've seen a need
On 19 December 2012 18:40, Tom Lane wrote:
> Robert Haas writes:
>> On Tue, Dec 18, 2012 at 3:39 PM, Kohei KaiGai wrote:
>>> postgres=> INSERT INTO t1 VALUES (4,'ddd');
>>> INSERT 0 1
>>> postgres=> INSERT INTO t1 VALUES (5,'eee');
>>> ERROR: new row for relation "t1" violates row-secirity
>>>
Robert Haas writes:
> On Tue, Dec 18, 2012 at 3:39 PM, Kohei KaiGai wrote:
>> postgres=> INSERT INTO t1 VALUES (4,'ddd');
>> INSERT 0 1
>> postgres=> INSERT INTO t1 VALUES (5,'eee');
>> ERROR: new row for relation "t1" violates row-secirity
>> DETAIL: Failing row contains (5, eee).
> I've argu
On 19 December 2012 17:25, Robert Haas wrote:
> On Tue, Dec 18, 2012 at 3:39 PM, Kohei KaiGai wrote:
>> postgres=> INSERT INTO t1 VALUES (4,'ddd');
>> INSERT 0 1
>> postgres=> INSERT INTO t1 VALUES (5,'eee');
>> ERROR: new row for relation "t1" violates row-secirity
>> DETAIL: Failing row conta
On Tue, Dec 18, 2012 at 3:39 PM, Kohei KaiGai wrote:
> postgres=> INSERT INTO t1 VALUES (4,'ddd');
> INSERT 0 1
> postgres=> INSERT INTO t1 VALUES (5,'eee');
> ERROR: new row for relation "t1" violates row-secirity
> DETAIL: Failing row contains (5, eee).
I've argued against this before - and m
2012/12/9 Simon Riggs :
> On 9 December 2012 06:08, Kohei KaiGai wrote:
>> 2012/12/7 Simon Riggs :
>>> On 5 December 2012 11:16, Kohei KaiGai wrote:
>>>
> * TRUNCATE works, and allows you to remove all rows of a table, even
> ones you can't see to run a DELETE on. Er...
>
It was
On 9 December 2012 06:08, Kohei KaiGai wrote:
> 2012/12/7 Simon Riggs :
>> On 5 December 2012 11:16, Kohei KaiGai wrote:
>>
* TRUNCATE works, and allows you to remove all rows of a table, even
ones you can't see to run a DELETE on. Er...
>>> It was my oversight. My preference is to
On 9 December 2012 06:21, Kohei KaiGai wrote:
> 2012/12/7 Simon Riggs :
>> On 5 December 2012 11:16, Kohei KaiGai wrote:
>>
Oracle defaults to putting VPD on all event types: INSERT, UPDATE,
DELETE, SELECT. ISTM we should be doing the same, not just say "we can
add an INSERT trigge
2012/12/7 Simon Riggs :
> On 5 December 2012 11:16, Kohei KaiGai wrote:
>
>>> Oracle defaults to putting VPD on all event types: INSERT, UPDATE,
>>> DELETE, SELECT. ISTM we should be doing the same, not just say "we can
>>> add an INSERT trigger if you want".
>>>
>>> Adding a trigger just begs the
2012/12/7 Simon Riggs :
> On 5 December 2012 11:16, Kohei KaiGai wrote:
>
>>> * TRUNCATE works, and allows you to remove all rows of a table, even
>>> ones you can't see to run a DELETE on. Er...
>>>
>> It was my oversight. My preference is to rewrite TRUNCATE command
>> with DELETE statement in c
On 5 December 2012 11:16, Kohei KaiGai wrote:
>> Oracle defaults to putting VPD on all event types: INSERT, UPDATE,
>> DELETE, SELECT. ISTM we should be doing the same, not just say "we can
>> add an INSERT trigger if you want".
>>
>> Adding a trigger just begs the question as to why we are bothe
On 5 December 2012 11:16, Kohei KaiGai wrote:
>> * TRUNCATE works, and allows you to remove all rows of a table, even
>> ones you can't see to run a DELETE on. Er...
>>
> It was my oversight. My preference is to rewrite TRUNCATE command
> with DELETE statement in case when row-security policy is
Thanks for your reviewing in spite of large number of lines.
My comments are below.
2012/12/4 Simon Riggs :
> Patch looks good and also like it will/can be ready for 9.3. I'm happy
> to put time into this as committer and/or reviewer and take further
> responsibility for it, unless others wish to
Patch looks good and also like it will/can be ready for 9.3. I'm happy
to put time into this as committer and/or reviewer and take further
responsibility for it, unless others wish to.
LIKES
* It's pretty simple to understand and use
* Check qual is stored in pre-parsed form. That is fast, and a
66 matches
Mail list logo
