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
22 matches
Mail list logo
