On 19 September 2014 17:54, Stephen Frost sfr...@snowman.net wrote:
Thom,
* Thom Brown (t...@linux.com) wrote:
On 19 September 2014 17:32, Stephen Frost sfr...@snowman.net wrote:
* Thom Brown (t...@linux.com) wrote:
On 14 September 2014 16:38, Stephen Frost sfr...@snowman.net wrote:
Thom,
* Thom Brown (t...@linux.com) wrote:
I find it a bit of a limitation that I can't specify both INSERT and
UPDATE for a policy. I'd want to be able to specify something like
this:
CREATE POLICY no_greys_allowed
ON colours
FOR INSERT, UPDATE
WITH CHECK (name NOT IN
On 25 September 2014 15:26, Stephen Frost sfr...@snowman.net wrote:
I expected this to still trigger an error due to the first policy. Am
I to infer from this that the policy model is permissive rather than
restrictive?
That's correct and I believe pretty clear in the documentation- policies
On 09/20/2014 12:38 AM, Stephen Frost wrote:
I would not (nor do I feel that I did..) have committed it over a
specific request to not do so from another committer. I had been hoping
that there would be another review coming from somewhere, but there is
always a trade-off between waiting
On 09/20/2014 12:23 AM, Craig Ringer wrote:
On 09/20/2014 12:38 AM, Stephen Frost wrote:
I would not (nor do I feel that I did..) have committed it over a
specific request to not do so from another committer. I had been hoping
that there would be another review coming from somewhere, but
On Sun, Sep 14, 2014 at 11:38 AM, Stephen Frost sfr...@snowman.net wrote:
* Robert Haas (robertmh...@gmail.com) wrote:
On Thu, Sep 11, 2014 at 3:08 PM, Stephen Frost sfr...@snowman.net wrote:
If we want to be able to disable RLS w/o dropping the policies, then I
think we have to completely
On 2014-09-19 11:53:06 -0400, Robert Haas wrote:
On Sun, Sep 14, 2014 at 11:38 AM, Stephen Frost sfr...@snowman.net wrote:
* Robert Haas (robertmh...@gmail.com) wrote:
On Thu, Sep 11, 2014 at 3:08 PM, Stephen Frost sfr...@snowman.net wrote:
If we want to be able to disable RLS w/o dropping
On 14 September 2014 16:38, Stephen Frost sfr...@snowman.net wrote:
* Robert Haas (robertmh...@gmail.com) wrote:
On Thu, Sep 11, 2014 at 3:08 PM, Stephen Frost sfr...@snowman.net
wrote:
If we want to be able to disable RLS w/o dropping the policies, then I
think we have to completely
Thom,
Thanks!
* Thom Brown (t...@linux.com) wrote:
On 14 September 2014 16:38, Stephen Frost sfr...@snowman.net wrote:
# create policy visible_colours on colours for all to joe using (visible =
true);
CREATE POLICY
[...]
insert into colours (name, visible) values ('transparent',false);
Robert,
* Robert Haas (robertmh...@gmail.com) wrote:
On Sun, Sep 14, 2014 at 11:38 AM, Stephen Frost sfr...@snowman.net wrote:
Alright, updated patch attached which does just that (thanks to Adam
for the updates for this and testing pg_dump- I just reviewed it and
added some documentation
On 19 September 2014 17:32, Stephen Frost sfr...@snowman.net wrote:
Thom,
Thanks!
* Thom Brown (t...@linux.com) wrote:
On 14 September 2014 16:38, Stephen Frost sfr...@snowman.net wrote:
# create policy visible_colours on colours for all to joe using (visible
=
true);
CREATE POLICY
On 2014-09-19 12:38:39 -0400, Stephen Frost wrote:
I would not (nor do I feel that I did..) have committed it over a
specific request to not do so from another committer. I had been hoping
that there would be another review coming from somewhere, but there is
always a trade-off between
On Fri, Sep 19, 2014 at 12:38 PM, Stephen Frost sfr...@snowman.net wrote:
This patch, on the other hand, was massively revised after the start
of the CommitFest after many months of inactivity and committed with
no thorough review by anyone who was truly independent of the
development effort.
Thom,
* Thom Brown (t...@linux.com) wrote:
On 19 September 2014 17:32, Stephen Frost sfr...@snowman.net wrote:
* Thom Brown (t...@linux.com) wrote:
On 14 September 2014 16:38, Stephen Frost sfr...@snowman.net wrote:
# create policy visible_colours on colours for all to joe using (visible
Thom,
Also, I seem to get an error message with the following:
# create policy nice_colours ON colours for all to joe using (visible =
true) with check (name in ('blue','green','yellow'));
CREATE POLICY
\c - joe
insert into colours (name, visible) values ('blue',false);
ERROR: function
Adam == Brightwell, Adam adam.brightw...@crunchydatasolutions.com
writes:
Adam At any rate, this appears to be a previously existing issue
Adam with WITH CHECK OPTION. Thoughts?
It's definitely an existing issue; you can reproduce it more simply,
no need to mess with different users.
The
On Wed, September 10, 2014 23:50, Stephen Frost wrote:
[rls_9-10-2014.patch]
I can't get this to apply; I attach the complaints of patch.
Erik Rijkers
-- git clone git://git.postgresql.org/git/postgresql.git master
Cloning into 'master'...
-- git branch
* master
patching file
Erik,
* Erik Rijkers (e...@xs4all.nl) wrote:
On Wed, September 10, 2014 23:50, Stephen Frost wrote:
[rls_9-10-2014.patch]
I can't get this to apply; I attach the complaints of patch.
Thanks for taking a look at this!
[...]
patching file src/include/catalog/catversion.h
Hunk #1 FAILED
On Sat, Sep 6, 2014 at 2:54 AM, Brightwell, Adam
adam.brightw...@crunchydatasolutions.com wrote:
* Add ALTER TABLE name { ENABLE | DISABLE } ROW LEVEL SECURITY - set flag
on table to allow for a default-deny capability. If RLS is enabled on a
table and has no policies, then a default-deny
Robert,
* Robert Haas (robertmh...@gmail.com) wrote:
On Sat, Sep 6, 2014 at 2:54 AM, Brightwell, Adam
adam.brightw...@crunchydatasolutions.com wrote:
* Add ALTER TABLE name { ENABLE | DISABLE } ROW LEVEL SECURITY - set flag
on table to allow for a default-deny capability. If RLS is enabled
On Thu, Sep 11, 2014 at 3:08 PM, Stephen Frost sfr...@snowman.net wrote:
2. Row level security policies can exist for a table with DISABLE ROW
LEVEL SECURITY in effect, but they don't do anything until RLS is
enabled. A possible advantage of this approach is that you could
*temporarily* shut
* Robert Haas (robertmh...@gmail.com) wrote:
On Thu, Sep 11, 2014 at 3:08 PM, Stephen Frost sfr...@snowman.net wrote:
The one thing I'm wondering about with this design is- what happens when
a policy is initially added? Currently, we automatically turn on RLS
for the table when that
On Fri, Aug 29, 2014 at 8:16 PM, Brightwell, Adam
adam.brightw...@crunchydatasolutions.com wrote:
Attached is a patch for RLS that was create against master at
01363beae52700c7425cb2d2452177133dad3e93 and is ready for review.
Overview:
This patch provides the capability to create multiple
Hey Robert,
On my phone at the moment but wanted to reply.
I'm working through a few of these issues already actually (noticed as I've
been going over it with Adam), but certainly appreciate the additional
review. We've not posted another update quite yet but plan to shortly.
Thanks!
Stephen
Robert,
Alright, I can't help it so I'll try and reply from my phone for a couple
of these. :)
On Wednesday, September 3, 2014, Robert Haas robertmh...@gmail.com wrote:
On Fri, Aug 29, 2014 at 8:16 PM, Brightwell, Adam
adam.brightw...@crunchydatasolutions.com javascript:; wrote:
Attached is
On Wed, Sep 3, 2014 at 10:40 AM, Stephen Frost sfr...@snowman.net wrote:
This is not a full review of this patch; as we're mid-CommitFest, I
assume this will get added to the next CommitFest.
As per usual, the expectation is that the patch is reviewed and updated
during the commitfest. Given
Adam, all,
* Brightwell, Adam (adam.brightw...@crunchydatasolutions.com) wrote:
Attached is a patch for RLS that was create against master at
01363beae52700c7425cb2d2452177133dad3e93 and is ready for review.
Many thanks for posting this. As others may realize already, I've
reviewed and
On Fri, Jul 18, 2014 at 7:01 PM, Brightwell, Adam
adam.brightw...@crunchydatasolutions.com wrote:
I think we do want a way to modify policies. However, we tend to
avoid syntax that involves unnatural word order, as this certainly
does. Maybe it's better to follow the example of CREATE RULE
On Wed, Jul 16, 2014 at 10:04 PM, Brightwell, Adam
adam.brightw...@crunchydatasolutions.com wrote:
Yes, I just tested it and the following would work from a grammar
perspective:
ALTER TABLE table_name POLICY ADD policy_name (policy_quals)
ALTER TABLE table_name POLICY DROP policy_name
I think we do want a way to modify policies. However, we tend to
avoid syntax that involves unnatural word order, as this certainly
does. Maybe it's better to follow the example of CREATE RULE and
CREATE TRIGGER and do something this instead:
CREATE POLICY policy_name ON table_name USING
Tom Lane wrote:
20MB messages to the list aren't that friendly. Please don't do that
again, unless asked to.
FWIW the message was not distributed to the list. I got a note from
Adam and dropped it from the moderation queue.
--
Álvaro Herrerahttp://www.2ndQuadrant.com/
Brightwell, Adam adam.brightw...@crunchydatasolutions.com writes:
You could do:
ALTER TABLE table_name ADD POLICY policy_name (quals);
ALTER TABLE table_name POLICY FOR role_name IS policy_name;
ALTER TABLE table_name DROP POLICY policy_name;
I am attempting to modify the grammar to
Adam,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
Brightwell, Adam adam.brightw...@crunchydatasolutions.com writes:
ALTER TABLE table_name ADD POLICY policy_name (quals);
ALTER TABLE table_name POLICY FOR role_name IS policy_name;
ALTER TABLE table_name DROP POLICY policy_name;
[...]
This
Tom,
Thanks for the feedback.
20MB messages to the list aren't that friendly. Please don't do that
again, unless asked to.
Apologies, I didn't realize it was so large until after it was sent. At
any rate, it won't happen again.
FWIW, the above syntax is a nonstarter, at least unless
Stephen,
Yeah, now that we're trying to bake this into ALTER TABLE we need to be
a bit more cautious. I'd think:
ALTER TABLE tab POLICY ADD ...
Would work though? (note: haven't looked/tested myself)
Yes, I just tested it and the following would work from a grammar
perspective:
ALTER
Adam,
* Brightwell, Adam (adam.brightw...@crunchydatasolutions.com) wrote:
Yeah, now that we're trying to bake this into ALTER TABLE we need to be
a bit more cautious. I'd think:
ALTER TABLE tab POLICY ADD ...
Would work though? (note: haven't looked/tested myself)
Yes, I just
On Thursday, July 10, 2014, Robert Haas robertmh...@gmail.com wrote:
On Wed, Jul 9, 2014 at 2:13 AM, Stephen Frost sfr...@snowman.net
javascript:; wrote:
Yes, this would be possible (and is nearly identical to the original
patch, except that this includes per-role considerations), however,
On Fri, Jul 11, 2014 at 4:55 AM, Stephen Frost sfr...@snowman.net wrote:
On Thursday, July 10, 2014, Robert Haas robertmh...@gmail.com wrote:
On Wed, Jul 9, 2014 at 2:13 AM, Stephen Frost sfr...@snowman.net wrote:
Yes, this would be possible (and is nearly identical to the original
patch,
Robert,
On Friday, July 11, 2014, Robert Haas robertmh...@gmail.com wrote:
On Fri, Jul 11, 2014 at 4:55 AM, Stephen Frost sfr...@snowman.net
javascript:; wrote:
My feeling at the moment is that having them be per-table makes sense and
we'd still have flexibility to change later if we had
On Wed, Jul 9, 2014 at 2:13 AM, Stephen Frost sfr...@snowman.net wrote:
Robert,
* Robert Haas (robertmh...@gmail.com) wrote:
If you're going to have predicates be table-level and access grants be
table-level, then what's the value in having policies? You could just
do:
ALTER TABLE
Craig,
* Craig Ringer (cr...@2ndquadrant.com) wrote:
I was jotting notes about this last sleepless night, and was really glad
to see the suggestion of enabling RLS on a table being a requirement for
OR-style quals suggested in the thread when I woke.
Thanks for your thoughts and input!
The
KaiGai,
* Kohei KaiGai (kai...@kaigai.gr.jp) wrote:
What I'd like to implement is adjustment of query like:
SELECT * FROM t1 WHERE (x like '%abc%') AND (quals by built-in RLS)
AND (quals by extension-1) AND ... AND (quals by extension-N);
I never mind even if qualifiers in the
Robert,
* Robert Haas (robertmh...@gmail.com) wrote:
If you're going to have predicates be table-level and access grants be
table-level, then what's the value in having policies? You could just
do:
ALTER TABLE table_name GRANT ROW ACCESS TO role_name USING quals;
Yes, this would be
2014-07-09 15:07 GMT+09:00 Stephen Frost sfr...@snowman.net:
KaiGai,
* Kohei KaiGai (kai...@kaigai.gr.jp) wrote:
What I'd like to implement is adjustment of query like:
SELECT * FROM t1 WHERE (x like '%abc%') AND (quals by built-in RLS)
AND (quals by extension-1) AND ... AND
KaiGai,
* Kohei KaiGai (kai...@kaigai.gr.jp) wrote:
2014-07-09 15:07 GMT+09:00 Stephen Frost sfr...@snowman.net:
* Kohei KaiGai (kai...@kaigai.gr.jp) wrote:
What I'd like to implement is adjustment of query like:
SELECT * FROM t1 WHERE (x like '%abc%') AND (quals by built-in RLS)
Hi all
I was jotting notes about this last sleepless night, and was really glad
to see the suggestion of enabling RLS on a table being a requirement for
OR-style quals suggested in the thread when I woke.
The only sane way to do OR-ing of multiple rules is to require that
tables be switched to
2014-07-06 14:19 GMT+09:00 Stephen Frost sfr...@snowman.net:
Kaigai,
* Kouhei Kaigai (kai...@ak.jp.nec.com) wrote:
Can you clarify where this is coming from..? It sounds like you're
referring to an existing implementation and, if so, it'd be good to get
more information on how that works
On Thu, Jul 3, 2014 at 1:14 AM, Stephen Frost sfr...@snowman.net wrote:
Alright, apologies for it being a bit later than intended, but here's
what I've come up with thus far.
-- policies defined at a table scope
-- allows using the same policy name for different tables
-- with quals
Kaigai,
* Kouhei Kaigai (kai...@ak.jp.nec.com) wrote:
Can you clarify where this is coming from..? It sounds like you're
referring to an existing implementation and, if so, it'd be good to get
more information on how that works exactly.
Oracle VPD - Multiple Policies for Each Table,
Sorry for my late responding, now I'm catching up the discussion.
* Robert Haas (robertmh...@gmail.com) wrote:
On Tue, Jul 1, 2014 at 3:20 PM, Dean Rasheed dean.a.rash...@gmail.com
wrote:
If RLS quals are instead regarded as constraints on access, and
multiple policies apply, then it
Kaigai,
On Thursday, July 3, 2014, Kouhei Kaigai kai...@ak.jp.nec.com wrote:
Sorry for my late responding, now I'm catching up the discussion.
* Robert Haas (robertmh...@gmail.com javascript:;) wrote:
On Tue, Jul 1, 2014 at 3:20 PM, Dean Rasheed dean.a.rash...@gmail.com
javascript:;
Kaigai,
On Thursday, July 3, 2014, Kouhei Kaigai kai...@ak.jp.nec.com wrote:
Sorry for my late responding, now I'm catching up the discussion.
* Robert Haas (robertmh...@gmail.com javascript:; ) wrote:
On Tue, Jul 1, 2014 at 3:20 PM, Dean Rasheed
On 01/07/14 21:51, Robert Haas wrote:
On Tue, Jul 1, 2014 at 3:20 PM, Dean Rasheed dean.a.rash...@gmail.com wrote:
That seems like a pretty strong argument.
If RLS quals are instead regarded as constraints on access, and
multiple policies apply, then it seems that the quals should now be
* Robert Haas (robertmh...@gmail.com) wrote:
On Tue, Jul 1, 2014 at 3:20 PM, Dean Rasheed dean.a.rash...@gmail.com wrote:
If RLS quals are instead regarded as constraints on access, and
multiple policies apply, then it seems that the quals should now be
combined with AND rather than OR,
On Wed, Jul 2, 2014 at 9:47 AM, Stephen Frost sfr...@snowman.net wrote:
But you could do it other ways. For example:
ALTER TABLE table_name [ NO ] ROW LEVEL SECURITY;
ALTER TABLE table_name GRANT ROW ACCESS TO role_name USING qual;
If a table is set to NO ROW LEVEL SECURITY then it behaves
* Robert Haas (robertmh...@gmail.com) wrote:
On Wed, Jul 2, 2014 at 9:47 AM, Stephen Frost sfr...@snowman.net wrote:
But you could do it other ways. For example:
ALTER TABLE table_name [ NO ] ROW LEVEL SECURITY;
ALTER TABLE table_name GRANT ROW ACCESS TO role_name USING qual;
If a
On Wed, Jul 2, 2014 at 11:42 AM, Stephen Frost sfr...@snowman.net wrote:
What if policies exist and they decide to
'turn off' RLS for the table- suddenly everyone can see all the rows?
That'd be my vote. Sorta like disabling triggers.
Hmm. Ok- how would you feel about at least spitting
* Robert Haas (robertmh...@gmail.com) wrote:
On Wed, Jul 2, 2014 at 11:42 AM, Stephen Frost sfr...@snowman.net wrote:
What if policies exist and they decide to
'turn off' RLS for the table- suddenly everyone can see all the rows?
That'd be my vote. Sorta like disabling triggers.
Robert, all,
* Robert Haas (robertmh...@gmail.com) wrote:
I think we're converging, but it might be a good idea to summarize a
specific proposal before you start implementing.
Alright, apologies for it being a bit later than intended, but here's
what I've come up with thus far.
-- policies
On 29 June 2014 20:42, Stephen Frost sfr...@snowman.net wrote:
To try and clarify what this distinction is-
Dean's approach with GRANT allows specifying the policy to be
used when a given role queries a given table. Through this mechanism,
one role might have access to many different tables,
On Tue, Jul 1, 2014 at 3:33 AM, Dean Rasheed dean.a.rash...@gmail.com wrote:
An annoying complication, however, is how this interacts with column
privileges. Right now GRANT SELECT(col1) ON t1 TO role1 gives role1
access to every row in col1, and I think that has to remain the case,
since
On 1 July 2014 17:42, Robert Haas robertmh...@gmail.com wrote:
On Tue, Jul 1, 2014 at 3:33 AM, Dean Rasheed dean.a.rash...@gmail.com wrote:
An annoying complication, however, is how this interacts with column
privileges. Right now GRANT SELECT(col1) ON t1 TO role1 gives role1
access to every
On Tue, Jul 1, 2014 at 3:20 PM, Dean Rasheed dean.a.rash...@gmail.com wrote:
On 1 July 2014 17:42, Robert Haas robertmh...@gmail.com wrote:
On Tue, Jul 1, 2014 at 3:33 AM, Dean Rasheed dean.a.rash...@gmail.com
wrote:
An annoying complication, however, is how this interacts with column
On Sun, Jun 29, 2014 at 3:42 PM, Stephen Frost sfr...@snowman.net wrote:
An interesting question we haven't much considered is: who can set up
policies and add then to users? Maybe we should flip this around, and
instead of adding users to policies, we should exempt users from
policies.
* Robert Haas (robertmh...@gmail.com) wrote:
On Sun, Jun 29, 2014 at 3:42 PM, Stephen Frost sfr...@snowman.net wrote:
An interesting question we haven't much considered is: who can set up
policies and add then to users? Maybe we should flip this around, and
instead of adding users to
On Mon, Jun 30, 2014 at 9:42 AM, Stephen Frost sfr...@snowman.net wrote:
I'm not a fan of the EXEMPT approach..
Just out of curiosity, why not?
I don't see it as really solving the flexibility need and it feels quite
a bit more complicated to reason about. Would someone who is EXEMPT
from
* Robert Haas (robertmh...@gmail.com) wrote:
On Mon, Jun 30, 2014 at 9:42 AM, Stephen Frost sfr...@snowman.net wrote:
I don't see it as really solving the flexibility need and it feels quite
a bit more complicated to reason about. Would someone who is EXEMPT
from one policy on a given
Robert, Dean,
* Dean Rasheed (dean.a.rash...@gmail.com) wrote:
On 26 June 2014 18:04, Robert Haas robertmh...@gmail.com wrote:
ALTER TABLE t1 SET POLICY p1 ON SELECT TO t1_p1_sel_quals;
GRANT SELECT ON TABLE t1 TO role1 USING p1;
As I see it, the downside of this is that it gets a lot
On 26 June 2014 18:04, Robert Haas robertmh...@gmail.com wrote:
ALTER TABLE t1 SET POLICY p1 ON SELECT TO t1_p1_sel_quals;
GRANT SELECT ON TABLE t1 TO role1 USING p1;
As I see it, the downside of this is that it gets a lot more complex.
We have to revise the ACL representation, which is
On Wed, Jun 25, 2014 at 4:48 PM, Dean Rasheed dean.a.rash...@gmail.com wrote:
Instead of doing it this way, we could instead do:
ALTER ROLE role1 ADD POLICY p1;
ALTER ROLE role2 ADD POLICY p2;
We could possibly allow multiple policies to be set for the same user,
but given an error (or OR
On 25 June 2014 01:49, Stephen Frost sfr...@snowman.net wrote:
Dean, all,
Changing the subject of this thread (though keeping it threaded) as
we've really moved on to a much broader discussion.
* Dean Rasheed (dean.a.rash...@gmail.com) wrote:
On 24 June 2014 17:27, Stephen Frost
* Dean Rasheed (dean.a.rash...@gmail.com) wrote:
On 25 June 2014 01:49, Stephen Frost sfr...@snowman.net wrote:
I can't recall a system where managers have to request access to their
manager role. Having another way of changing the permissions which are
applied to a session (the existing
Robert, all,
Changing the thread topic to match the other one, and adding Dean in
explicitly since we're talking about the design discussed with him.
* Robert Haas (robertmh...@gmail.com) wrote:
I think role is good enough. That's the primary identifier for all
access-control related
On Tue, Jun 24, 2014 at 8:49 PM, Stephen Frost sfr...@snowman.net wrote:
Let's try to outline what this would look like then.
Taking your approach, we'd have:
CREATE POLICY p1;
CREATE POLICY p2;
ALTER TABLE t1 SET POLICY p1 TO t1_p1_quals;
ALTER TABLE t1 SET POLICY p2 TO t1_p2_quals;
* Robert Haas (robertmh...@gmail.com) wrote:
On Tue, Jun 24, 2014 at 8:49 PM, Stephen Frost sfr...@snowman.net wrote:
Let's try to outline what this would look like then.
Taking your approach, we'd have:
CREATE POLICY p1;
CREATE POLICY p2;
ALTER TABLE t1 SET POLICY p1 TO
On 25 June 2014 16:44, Robert Haas robertmh...@gmail.com wrote:
On Tue, Jun 24, 2014 at 8:49 PM, Stephen Frost sfr...@snowman.net wrote:
Let's try to outline what this would look like then.
Taking your approach, we'd have:
CREATE POLICY p1;
CREATE POLICY p2;
ALTER TABLE t1 SET POLICY p1
Dean, all,
Changing the subject of this thread (though keeping it threaded) as
we've really moved on to a much broader discussion.
* Dean Rasheed (dean.a.rash...@gmail.com) wrote:
On 24 June 2014 17:27, Stephen Frost sfr...@snowman.net wrote:
Single policy vs Multiple, Overlapping policies vs
77 matches
Mail list logo
