On 25 April 2015 at 01:52, Stephen Frost wrote:
> * Dean Rasheed (dean.a.rash...@gmail.com) wrote:
>> The second patch [2] is the one that is actually relevant to this
>> thread. This patch is primarily to apply the RLS checks earlier,
>> before an update is attempted, more like a regular permissi
Dean,
* Dean Rasheed (dean.a.rash...@gmail.com) wrote:
> The second patch [2] is the one that is actually relevant to this
> thread. This patch is primarily to apply the RLS checks earlier,
> before an update is attempted, more like a regular permissions check.
> This adds a new enum to classify t
Dean,
* Dean Rasheed (dean.a.rash...@gmail.com) wrote:
> On 21 April 2015 at 20:50, Stephen Frost wrote:
> > Thanks a lot for this. Please take a look at the attached.
>
> I've given this a quick read-through, and it looks good to me. The
> interaction of permissive and restrictive policies fro
On 22 April 2015 at 17:02, Stephen Frost wrote:
> Pushed with those changes, please take a look and test!
>
Excellent, thanks! Will test.
Regards,
Dean
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpre
Dean,
* Dean Rasheed (dean.a.rash...@gmail.com) wrote:
> On 21 April 2015 at 22:21, Dean Rasheed wrote:
> > On 21 April 2015 at 20:50, Stephen Frost wrote:
> >> Thanks a lot for this. Please take a look at the attached.
> >
> > I've given this a quick read-through, and it looks good to me. The
Dean,
* Dean Rasheed (dean.a.rash...@gmail.com) wrote:
> On 21 April 2015 at 22:21, Dean Rasheed wrote:
> > On 21 April 2015 at 20:50, Stephen Frost wrote:
> >> Thanks a lot for this. Please take a look at the attached.
> >
> > I've given this a quick read-through, and it looks good to me. The
On 21 April 2015 at 22:21, Dean Rasheed wrote:
> On 21 April 2015 at 20:50, Stephen Frost wrote:
>> Thanks a lot for this. Please take a look at the attached.
>
> I've given this a quick read-through, and it looks good to me. The
> interaction of permissive and restrictive policies from hooks ma
On 21 April 2015 at 20:50, Stephen Frost wrote:
> Thanks a lot for this. Please take a look at the attached.
I've given this a quick read-through, and it looks good to me. The
interaction of permissive and restrictive policies from hooks matches
my expections, and it's a definite improvement hav
Dean,
* Dean Rasheed (dean.a.rash...@gmail.com) wrote:
> On 7 April 2015 at 16:21, Stephen Frost wrote:
> > Agreed and we actually have a patch from Dean already to address this,
> > it's just been waiting on me (with a couple of other ones). It'd
> > certainly be great if you have time to take
On 9 April 2015 at 14:56, Dean Rasheed wrote:
> On 8 April 2015 at 16:27, Stephen Frost wrote:
> > * Dean Rasheed (dean.a.rash...@gmail.com) wrote:
> >> I actually re-used the sql status code 42501 -
> >> ERRCODE_INSUFFICIENT_PRIVILEGE for a RLS check failure because of the
> >> parallel with pe
* Craig Ringer (cr...@2ndquadrant.com) wrote:
> On 9 April 2015 at 01:30, Dean Rasheed wrote:
> > That doesn't match what the code currently does:
Ah, right.
> > * Also, allow extensions to add their own policies.
> > *
> > * Note that, as with the internal policies, if multiple p
On 8 April 2015 at 16:27, Stephen Frost wrote:
> * Dean Rasheed (dean.a.rash...@gmail.com) wrote:
>> I actually re-used the sql status code 42501 -
>> ERRCODE_INSUFFICIENT_PRIVILEGE for a RLS check failure because of the
>> parallel with permissions checks, but I quite like Craig's idea of
>> inve
On 9 April 2015 at 01:30, Dean Rasheed wrote:
>
> That doesn't match what the code currently does:
>
> * Also, allow extensions to add their own policies.
> *
> * Note that, as with the internal policies, if multiple policies are
> * returned then they will be combined into a
On 8 April 2015 at 19:52, Dean Rasheed wrote:
> 2). In prepend_row_security_policies(), I think it is better to have
> any table RLS policies applied before any hook policies, so that a
> hook cannot be used to bypass built-in RLS.
>
A hook really has to be able to ensure that built-in RLS cann
On 8 April 2015 at 16:27, Stephen Frost wrote:
>> 2). In prepend_row_security_policies(), I think it is better to have
>> any table RLS policies applied before any hook policies, so that a
>> hook cannot be used to bypass built-in RLS.
>
> While I agree that we want to include the RLS policies def
Dean,
* Dean Rasheed (dean.a.rash...@gmail.com) wrote:
> On 7 April 2015 at 16:21, Stephen Frost wrote:
> > Agreed and we actually have a patch from Dean already to address this,
> > it's just been waiting on me (with a couple of other ones). It'd
> > certainly be great if you have time to take
* Kevin Grittner (kgri...@ymail.com) wrote:
> Dean Rasheed wrote:
>
> >> Re-using the SQLSTATE 44000 is a bit iffy too. We should
> >> probably define something to differentiate this, like:
> >>
> >>44P01 ROW SECURITY WRITE POLICY VIOLATION
> >
> > Yes, that sounds sensible.
>
> I would be m
Dean Rasheed wrote:
>> Re-using the SQLSTATE 44000 is a bit iffy too. We should
>> probably define something to differentiate this, like:
>>
>>44P01 ROW SECURITY WRITE POLICY VIOLATION
>
> Yes, that sounds sensible.
I would be more inclined to use:
42501 ERRCODE_INSUFFICIENT_PRIVILEGE
I k
On 7 April 2015 at 16:21, Stephen Frost wrote:
> Agreed and we actually have a patch from Dean already to address this,
> it's just been waiting on me (with a couple of other ones). It'd
> certainly be great if you have time to take a look at those, though,
> generally speaking, I feel prety happ
On 7 April 2015 at 13:11, Craig Ringer wrote:
> When attempting to insert a row that violates a row security policy that
> applies to writes, the error message emitted references WITH CHECK OPTION,
> even though (as far as the user knows) there's no such thing involved.
> If you understand the int
On Tue, Apr 7, 2015 at 5:11 AM, Craig Ringer wrote:
> postgres=> INSERT INTO clients (account_name, account_manager) VALUES
> ('peters', 'peter'), ('johannas', 'johanna');
> ERROR: 44000: new row violates WITH CHECK OPTION for "clients"
> DETAIL: Failing row contains (7, johannas, johanna).
> LO
Craig,
* Craig Ringer (cr...@2ndquadrant.com) wrote:
> When attempting to insert a row that violates a row security policy that
> applies to writes, the error message emitted references WITH CHECK OPTION,
> even though (as far as the user knows) there's no such thing involved.
> If you understand
When attempting to insert a row that violates a row security policy that
applies to writes, the error message emitted references WITH CHECK OPTION,
even though (as far as the user knows) there's no such thing involved.
If you understand the internals you'd know that row security re-uses the
same lo
23 matches
Mail list logo
