On 25 September 2014 15:26, Stephen Frost 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
> are OR'd
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 ('gr
On 19 September 2014 17:54, Stephen Frost wrote:
>
> Thom,
>
> * Thom Brown (t...@linux.com) wrote:
> > On 19 September 2014 17:32, Stephen Frost wrote:
> > > * Thom Brown (t...@linux.com) wrote:
> > > > On 14 September 2014 16:38, Stephen Frost wrote:
> > > > # create policy visible_colours on
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,
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
> "Adam" == Brightwell, Adam
> 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 issue as far as I can tell
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:
Thom,
* Thom Brown (t...@linux.com) wrote:
> On 19 September 2014 17:32, Stephen Frost wrote:
> > * Thom Brown (t...@linux.com) wrote:
> > > On 14 September 2014 16:38, Stephen Frost wrote:
> > > # create policy visible_colours on colours for all to joe using (visible
> > =
> > > true);
> > > CR
On Fri, Sep 19, 2014 at 12:38 PM, Stephen Frost 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. It was the
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 wai
On 19 September 2014 17:32, Stephen Frost wrote:
> Thom,
>
> Thanks!
>
> * Thom Brown (t...@linux.com) wrote:
> > On 14 September 2014 16:38, Stephen Frost wrote:
> > # create policy visible_colours on colours for all to joe using (visible
> =
> > true);
> > CREATE POLICY
> [...]
> > > insert in
Robert,
* Robert Haas (robertmh...@gmail.com) wrote:
> On Sun, Sep 14, 2014 at 11:38 AM, Stephen Frost 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 updates and
Thom,
Thanks!
* Thom Brown (t...@linux.com) wrote:
> On 14 September 2014 16:38, Stephen Frost wrote:
> # create policy visible_colours on colours for all to joe using (visible =
> true);
> CREATE POLICY
[...]
> > insert into colours (name, visible) values ('transparent',false);
> ERROR: new ro
On 14 September 2014 16:38, Stephen Frost wrote:
> * Robert Haas (robertmh...@gmail.com) wrote:
> > On Thu, Sep 11, 2014 at 3:08 PM, Stephen Frost
> wrote:
> > > If we want to be able to disable RLS w/o dropping the policies, then I
> > > think we have to completely de-couple the two and users w
On 2014-09-19 11:53:06 -0400, Robert Haas wrote:
> On Sun, Sep 14, 2014 at 11:38 AM, Stephen Frost wrote:
> > * Robert Haas (robertmh...@gmail.com) wrote:
> >> On Thu, Sep 11, 2014 at 3:08 PM, Stephen Frost wrote:
> >> > If we want to be able to disable RLS w/o dropping the policies, then I
> >>
On Sun, Sep 14, 2014 at 11:38 AM, Stephen Frost wrote:
> * Robert Haas (robertmh...@gmail.com) wrote:
>> On Thu, Sep 11, 2014 at 3:08 PM, Stephen Frost wrote:
>> > If we want to be able to disable RLS w/o dropping the policies, then I
>> > think we have to completely de-couple the two and users w
* Robert Haas (robertmh...@gmail.com) wrote:
> On Thu, Sep 11, 2014 at 3:08 PM, Stephen Frost 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 happens. I'm not
On Thu, Sep 11, 2014 at 3:08 PM, Stephen Frost 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 off RLS for
Robert,
* Robert Haas (robertmh...@gmail.com) wrote:
> On Sat, Sep 6, 2014 at 2:54 AM, Brightwell, Adam
> wrote:
> > * Add ALTER TABLE { 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, th
On Sat, Sep 6, 2014 at 2:54 AM, Brightwell, Adam
wrote:
> * Add ALTER TABLE { 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 policy is automatically
> applied. If RLS is
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 FA
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 doc/src/s
On Wed, Sep 3, 2014 at 10:40 AM, Stephen Frost 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 that the co
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 wrote:
> On Fri, Aug 29, 2014 at 8:16 PM, Brightwell, Adam
> > wrote:
> > Attached is a patch for RLS that was create against master at
> > 01363beae52700c
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
On Fri, Aug 29, 2014 at 8:16 PM, Brightwell, Adam
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 named row level
> security policies f
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 modif
On Fri, Jul 18, 2014 at 7:01 PM, Brightwell, Adam
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 and
>> CREATE TRIGGER and do somethin
>
> 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
On Wed, Jul 16, 2014 at 10:04 PM, Brightwell, Adam
wrote:
> Yes, I just tested it and the following would work from a grammar
> perspective:
>
> ALTER TABLE POLICY ADD (policy_quals)
> ALTER TABLE POLICY DROP
>
> Though, it would obviously require the addition of POLICY to the list of
> unres
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/
Post
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)
>
> Y
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:
ALT
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 we
Adam,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> "Brightwell, Adam" 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 actually isn't just bison being
"Brightwell, Adam" 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 support the above syntax.
> Unfor
Robert,
On Friday, July 11, 2014, Robert Haas wrote:
> On Fri, Jul 11, 2014 at 4:55 AM, Stephen Frost > 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 some compelling
> reason
> > to do so.
>
> I don
On Fri, Jul 11, 2014 at 4:55 AM, Stephen Frost wrote:
> On Thursday, July 10, 2014, Robert Haas wrote:
>> On Wed, Jul 9, 2014 at 2:13 AM, Stephen Frost wrote:
>> > Yes, this would be possible (and is nearly identical to the original
>> > patch, except that this includes per-role considerations),
On Thursday, July 10, 2014, Robert Haas wrote:
> On Wed, Jul 9, 2014 at 2:13 AM, Stephen Frost > wrote:
> > Yes, this would be possible (and is nearly identical to the original
> > patch, except that this includes per-role considerations), however, my
> > thinking is that it'd be simpler to work
On Wed, Jul 9, 2014 at 2:13 AM, Stephen Frost 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 table_name GR
KaiGai,
* Kohei KaiGai (kai...@kaigai.gr.jp) wrote:
> 2014-07-09 15:07 GMT+09:00 Stephen Frost :
> > * 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)
> >> AN
2014-07-09 15:07 GMT+09:00 Stephen Frost :
> 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 exte
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 po
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
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!
> T
2014-07-06 14:19 GMT+09:00 Stephen Frost :
> 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 exactl
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 de
On Thu, Jul 3, 2014 at 1:14 AM, Stephen Frost 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 appropriate for each
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 Tab
> Kaigai,
>
> On Thursday, July 3, 2014, Kouhei Kaigai wrote:
>
>
> 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
> >
> > wrote:
> > > > If
Kaigai,
On Thursday, July 3, 2014, Kouhei Kaigai wrote:
> 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 >
> > wrote:
> > > > If RLS quals are instead regarded as constraint
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
> wrote:
> > > If RLS quals are instead regarded as constraints on access, and
> > > multiple policies apply, then it seems that the qu
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 d
* Robert Haas (robertmh...@gmail.com) wrote:
> On Wed, Jul 2, 2014 at 11:42 AM, Stephen Frost 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.
> >
> > Hm
On Wed, Jul 2, 2014 at 11:42 AM, Stephen Frost 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 out a WA
* Robert Haas (robertmh...@gmail.com) wrote:
> On Wed, Jul 2, 2014 at 9:47 AM, Stephen Frost 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 ta
On Wed, Jul 2, 2014 at 9:47 AM, Stephen Frost 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 just li
* Robert Haas (robertmh...@gmail.com) wrote:
> On Tue, Jul 1, 2014 at 3:20 PM, Dean Rasheed 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, right?
I do feel tha
On 01/07/14 21:51, Robert Haas wrote:
On Tue, Jul 1, 2014 at 3:20 PM, Dean Rasheed 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
combined with AND rather than
On Tue, Jul 1, 2014 at 3:20 PM, Dean Rasheed wrote:
> On 1 July 2014 17:42, Robert Haas wrote:
>> On Tue, Jul 1, 2014 at 3:33 AM, Dean Rasheed
>> wrote:
>>> An annoying complication, however, is how this interacts with column
>>> privileges. Right now "GRANT SELECT(col1) ON t1 TO role1" gives r
On 1 July 2014 17:42, Robert Haas wrote:
> On Tue, Jul 1, 2014 at 3:33 AM, Dean Rasheed 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 r
On Tue, Jul 1, 2014 at 3:33 AM, Dean Rasheed 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 GRANTs only ever give y
On 29 June 2014 20:42, Stephen Frost 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, possibly with
* Robert Haas (robertmh...@gmail.com) wrote:
> On Mon, Jun 30, 2014 at 9:42 AM, Stephen Frost 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 table still have
On Mon, Jun 30, 2014 at 9:42 AM, Stephen Frost 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 one pol
* Robert Haas (robertmh...@gmail.com) wrote:
> On Sun, Jun 29, 2014 at 3:42 PM, Stephen Frost 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
On Sun, Jun 29, 2014 at 3:42 PM, Stephen Frost 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, Dean,
* Dean Rasheed (dean.a.rash...@gmail.com) wrote:
> On 26 June 2014 18:04, Robert Haas 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.
On 26 June 2014 18:04, Robert Haas 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 already pretty darn
On Wed, Jun 25, 2014 at 4:48 PM, Dean Rasheed 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 the quals to
On 25 June 2014 16:44, Robert Haas wrote:
> On Tue, Jun 24, 2014 at 8:49 PM, Stephen Frost 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
* Robert Haas (robertmh...@gmail.com) wrote:
> On Tue, Jun 24, 2014 at 8:49 PM, Stephen Frost 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
On Tue, Jun 24, 2014 at 8:49 PM, Stephen Frost 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;
This seems li
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 decisio
* Dean Rasheed (dean.a.rash...@gmail.com) wrote:
> On 25 June 2014 01:49, Stephen Frost 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 one being 'se
On 25 June 2014 01:49, Stephen Frost 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 wrote:
>> > Single po
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 wrote:
> > Single policy vs Multiple, Overlapping policies vs Multiple,
> >
77 matches
Mail list logo
