2013/3/25 Simon Riggs si...@2ndquadrant.com:
On 19 March 2013 15:08, Kohei KaiGai kai...@kaigai.gr.jp 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
I moved Row Level Security patch to the 2013-Next commitfest.
2013/3/27 Kohei KaiGai kai...@kaigai.gr.jp:
2013/3/25 Simon Riggs si...@2ndquadrant.com:
On 19 March 2013 15:08, Kohei KaiGai kai...@kaigai.gr.jp wrote:
It is much helpful if someone give me comments around these
arguable portions
On 27 March 2013 10:57, Kohei KaiGai kai...@kaigai.gr.jp wrote:
2013/3/25 Simon Riggs si...@2ndquadrant.com:
On 19 March 2013 15:08, Kohei KaiGai kai...@kaigai.gr.jp wrote:
It is much helpful if someone give me comments around these
arguable portions from the standpoint with fresh eyes.
My
On 19 March 2013 15:08, Kohei KaiGai kai...@kaigai.gr.jp 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
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 syntax
2012/12/31 Simon Riggs si...@2ndquadrant.com:
On 23 December 2012 18:49, Simon Riggs si...@2ndquadrant.com 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
On Wed, Jan 02, 2013 at 05:35:13PM +0100, Kohei KaiGai wrote:
2012/12/31 Simon Riggs si...@2ndquadrant.com:
On 23 December 2012 18:49, Simon Riggs si...@2ndquadrant.com wrote:
Anyway, hope you can make call on 28th so we can discuss this and
agree a way forwards you're happy with.
On 2 January 2013 17:19, David Fetter da...@fetter.org 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
On Wed, Jan 02, 2013 at 05:31:42PM +, Simon Riggs wrote:
On 2 January 2013 17:19, David Fetter da...@fetter.org 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
On 23 December 2012 18:49, Simon Riggs si...@2ndquadrant.com 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.
On 22 December 2012 20:13, Kevin Grittner kgri...@mail.com 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
2012/12/22 Kevin Grittner kgri...@mail.com:
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
On 21 December 2012 16:51, Kevin Grittner kgri...@mail.com 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
Simon Riggs si...@2ndquadrant.com writes:
On 21 December 2012 16:51, Kevin Grittner kgri...@mail.com 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
On 23 December 2012 19:16, Tom Lane t...@sss.pgh.pa.us wrote:
Simon Riggs si...@2ndquadrant.com writes:
On 21 December 2012 16:51, Kevin Grittner kgri...@mail.com wrote:
If none, and this is strictly an optimization, what are the benchmarks
showing?
AFAIK its well known that a check
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
On 20 December 2012 19:42, Stephen Frost sfr...@snowman.net 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
On 21 December 2012 08:56, Simon Riggs si...@2ndquadrant.com 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
On 21 December 2012 09:29, Dean Rasheed dean.a.rash...@gmail.com wrote:
On 21 December 2012 08:56, Simon Riggs si...@2ndquadrant.com 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
On Thu, Dec 20, 2012 at 4:50 PM, Kevin Grittner kgri...@mail.com 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
On Fri, Dec 21, 2012 at 3:56 AM, Simon Riggs si...@2ndquadrant.com 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
On 21 December 2012 14:19, Robert Haas robertmh...@gmail.com wrote:
On Fri, Dec 21, 2012 at 3:56 AM, Simon Riggs si...@2ndquadrant.com 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
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 desired, but
On 21 December 2012 14:48, Kevin Grittner kgri...@mail.com 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
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(),
2012/12/21 Kevin Grittner kgri...@mail.com:
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
KaiGai, all,
* Kohei KaiGai (kai...@kaigai.gr.jp) wrote:
2012/12/21 Kevin Grittner kgri...@mail.com:
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
On 21 December 2012 22:01, Stephen Frost sfr...@snowman.net 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
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 contact
2012/12/21 Stephen Frost sfr...@snowman.net:
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
2012/12/22 Simon Riggs si...@2ndquadrant.com:
On 21 December 2012 22:01, Stephen Frost sfr...@snowman.net 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
On 20 December 2012 00:24, Robert Haas robertmh...@gmail.com wrote:
On Wed, Dec 19, 2012 at 12:54 PM, Simon Riggs si...@2ndquadrant.com 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
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
On Thu, Dec 20, 2012 at 4:35 AM, Simon Riggs si...@2ndquadrant.com 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
2012/12/20 Stephen Frost sfr...@snowman.net:
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
* 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 views.
I
2012/12/20 Robert Haas robertmh...@gmail.com:
On Thu, Dec 20, 2012 at 4:35 AM, Simon Riggs si...@2ndquadrant.com 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
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
On 20 December 2012 21:50, Kevin Grittner kgri...@mail.com 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
2012/12/20 Kevin Grittner kgri...@mail.com:
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
On Tue, Dec 18, 2012 at 3:39 PM, Kohei KaiGai kai...@kaigai.gr.jp 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
On 19 December 2012 17:25, Robert Haas robertmh...@gmail.com wrote:
On Tue, Dec 18, 2012 at 3:39 PM, Kohei KaiGai kai...@kaigai.gr.jp 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 robertmh...@gmail.com writes:
On Tue, Dec 18, 2012 at 3:39 PM, Kohei KaiGai kai...@kaigai.gr.jp 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
On 19 December 2012 18:40, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Tue, Dec 18, 2012 at 3:39 PM, Kohei KaiGai kai...@kaigai.gr.jp wrote:
postgres= INSERT INTO t1 VALUES (4,'ddd');
INSERT 0 1
postgres= INSERT INTO t1 VALUES (5,'eee');
ERROR: new row
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 19:46, Kevin Grittner kgri...@mail.com 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
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
later
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 allow
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
On 19 December 2012 20:23, Kevin Grittner kgri...@mail.com 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
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 unique
On 19 December 2012 20:37, Kevin Grittner kgri...@mail.com 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
Simon Riggs wrote:
Kevin Grittner kgri...@mail.com 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
On 2012-12-19 18:25, Robert Haas wrote:
On Tue, Dec 18, 2012 at 3:39 PM, Kohei KaiGai kai...@kaigai.gr.jp 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
On Wed, Dec 19, 2012 at 12:54 PM, Simon Riggs si...@2ndquadrant.com 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
On Wed, Dec 19, 2012 at 1:58 PM, Simon Riggs si...@2ndquadrant.com 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.
On 9 December 2012 06:21, Kohei KaiGai kai...@kaigai.gr.jp wrote:
2012/12/7 Simon Riggs si...@2ndquadrant.com:
On 5 December 2012 11:16, Kohei KaiGai kai...@kaigai.gr.jp wrote:
Oracle defaults to putting VPD on all event types: INSERT, UPDATE,
DELETE, SELECT. ISTM we should be doing the same,
On 9 December 2012 06:08, Kohei KaiGai kai...@kaigai.gr.jp wrote:
2012/12/7 Simon Riggs si...@2ndquadrant.com:
On 5 December 2012 11:16, Kohei KaiGai kai...@kaigai.gr.jp 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...
2012/12/9 Simon Riggs si...@2ndquadrant.com:
On 9 December 2012 06:08, Kohei KaiGai kai...@kaigai.gr.jp wrote:
2012/12/7 Simon Riggs si...@2ndquadrant.com:
On 5 December 2012 11:16, Kohei KaiGai kai...@kaigai.gr.jp wrote:
* TRUNCATE works, and allows you to remove all rows of a table, even
2012/12/7 Simon Riggs si...@2ndquadrant.com:
On 5 December 2012 11:16, Kohei KaiGai kai...@kaigai.gr.jp 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
2012/12/7 Simon Riggs si...@2ndquadrant.com:
On 5 December 2012 11:16, Kohei KaiGai kai...@kaigai.gr.jp 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
On 5 December 2012 11:16, Kohei KaiGai kai...@kaigai.gr.jp 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
On 5 December 2012 11:16, Kohei KaiGai kai...@kaigai.gr.jp 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
Thanks for your reviewing in spite of large number of lines.
My comments are below.
2012/12/4 Simon Riggs si...@2ndquadrant.com:
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,
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
66 matches
Mail list logo
