Noah,
* Noah Misch (n...@leadboat.com) wrote:
> On Mon, Sep 28, 2015 at 03:03:51PM -0400, Stephen Frost wrote:
> > If SELECT rights are required then apply the SELECT policies, even if
> > the actual command is an UPDATE or DELETE. This covers the RETURNING
> > case which was discussed previously
On Mon, Sep 28, 2015 at 03:03:51PM -0400, Stephen Frost wrote:
> If SELECT rights are required then apply the SELECT policies, even if
> the actual command is an UPDATE or DELETE. This covers the RETURNING
> case which was discussed previously, so we don't need the explicit check
> for that, and f
* Robert Haas (robertmh...@gmail.com) wrote:
> On Tue, Sep 15, 2015 at 10:22 AM, Stephen Frost wrote:
> > Unless there are other concerns or issues raised, I'll push this later
> > today.
>
> So does this mean that the first RLS open item is addressed? If so,
> can it be moved to the "resolved a
On Tue, Sep 15, 2015 at 10:22 AM, Stephen Frost wrote:
> Dean,
>
> * Dean Rasheed (dean.a.rash...@gmail.com) wrote:
>> A minor point -- this comment isn't quite right:
>
> Fixed.
>
>> because the policies that are fetched there are only used for
>> add_security_quals(), not for add_with_check_opti
Dean,
* Dean Rasheed (dean.a.rash...@gmail.com) wrote:
> On 15 September 2015 at 15:22, Stephen Frost wrote:
> > Updated patch attached for review.
> >
> > Unless there are other concerns or issues raised, I'll push this later
> > today.
>
> Looks good to me.
Excellent, pushed!
> Thanks for do
On 15 September 2015 at 15:22, Stephen Frost wrote:
> Updated patch attached for review.
>
> Unless there are other concerns or issues raised, I'll push this later
> today.
>
Looks good to me.
Thanks for doing all this.
Regards,
Dean
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postg
Dean,
* Dean Rasheed (dean.a.rash...@gmail.com) wrote:
> A minor point -- this comment isn't quite right:
Fixed.
> because the policies that are fetched there are only used for
> add_security_quals(), not for add_with_check_options(). It might be
> cleaner if the 'if' statement that follows were
Dean,
* Dean Rasheed (dean.a.rash...@gmail.com) wrote:
> On 14 September 2015 at 14:47, Stephen Frost wrote:
> > Attached is a git format-patch built series which includes both commits,
> > now broken out, for review.
>
> That looks OK to me.
Excellent.
> A minor point -- this comment isn't qu
On 14 September 2015 at 14:47, Stephen Frost wrote:
> Attached is a git format-patch built series which includes both commits,
> now broken out, for review.
>
That looks OK to me.
A minor point -- this comment isn't quite right:
/*
* For the target relation, when there is a returning l
Dean,
* Dean Rasheed (dean.a.rash...@gmail.com) wrote:
> It shouldn't be necessary to change get_policies_for_relation() at all
> to support the RETURNING check. You just need to call it with
> CMD_SELECT.
Yup, that works well.
> BTW, your change to change get_policies_for_relation() has
> a bug
On 13 September 2015 at 22:54, Stephen Frost wrote:
> Not in front of my laptop and will review it when I get back in more detail,
> but the original approach that I tried was changing
> get_policies_for_relation to try and build everything necessary, which
> didn't work as we need to OR the vario
Dean,
On Sunday, September 13, 2015, Dean Rasheed
wrote:
> On 13 September 2015 at 20:59, Stephen Frost > wrote:
> > I've been through this and definitely like it more than what we had
> > previously, as I had mentioned previously. I've also added the
> > RETURNING handling, per the discussion
On 13 September 2015 at 20:59, Stephen Frost wrote:
> I've been through this and definitely like it more than what we had
> previously, as I had mentioned previously. I've also added the
> RETURNING handling, per the discussion between you, Robert, Tom, and
> Kevin.
>
> Would be great to get your
Dean,
* Dean Rasheed (dean.a.rash...@gmail.com) wrote:
> OK, here's a rebased version of the patch.
Thanks!
> There are no significant changes from last time this was discussed. I
> believe the module regression test changes are harmless --- a result
> of a change in the order that SB quals are
On 11 September 2015 at 15:51, Joe Conway wrote:
> On 09/11/2015 04:33 AM, Stephen Frost wrote:
>> * Dean Rasheed (dean.a.rash...@gmail.com) wrote:
>>> I will happily work up a rebased version of the patch, but only if I
>>> get a serious commitment from a committer to review it. Otherwise,
>>> I'
Dean Rasheed wrote:
> Ultimately I think this will be an extremely rare case, probably more
> likely to happen as a result of accidentally misconfigured policies.
> But if that does happen, I'd rather have an error to alert me to the
> fact, than to silently do nothing.
I agree with Tom and Robe
On 11 September 2015 at 17:56, Tom Lane wrote:
> Dean Rasheed writes:
>> On 11 September 2015 at 15:49, Tom Lane wrote:
>>> However, I don't see why UPDATE/DELETE with RETURNING couldn't be
>>> restricted according to *both* the UPDATE and SELECT policies,
>>> ie if there's RETURNING then you ca
Dean Rasheed writes:
> On 11 September 2015 at 15:49, Tom Lane wrote:
>> However, I don't see why UPDATE/DELETE with RETURNING couldn't be
>> restricted according to *both* the UPDATE and SELECT policies,
>> ie if there's RETURNING then you can't update a row you could not
>> have selected. Note
On 11 September 2015 at 15:49, Tom Lane wrote:
> Dean Rasheed writes:
>> Yeah, we had a similar discussion regarding UPDATE USING policies and
>> ON CONFLICT UPDATE clauses. I think the argument against filtering is
>> that the rows returned would then be misleading about what was
>> actually upd
On Fri, Sep 11, 2015 at 9:48 AM, Stephen Frost wrote:
> The only reason to avoid providing that flexibility is the concern that
> it might be misunderstood and users might misconfigure their system.
> Removing the flexibility to have per-command visibility policies and
> instead force a single vis
On Fri, Sep 11, 2015 at 10:49 AM, Tom Lane wrote:
> Dean Rasheed writes:
>> Yeah, we had a similar discussion regarding UPDATE USING policies and
>> ON CONFLICT UPDATE clauses. I think the argument against filtering is
>> that the rows returned would then be misleading about what was
>> actually
On 09/11/2015 04:33 AM, Stephen Frost wrote:
> * Dean Rasheed (dean.a.rash...@gmail.com) wrote:
>> I will happily work up a rebased version of the patch, but only if I
>> get a serious commitment from a committer to review it. Otherwise,
>> I'll let it drop.
>
> There's no question about getting i
Dean Rasheed writes:
> Yeah, we had a similar discussion regarding UPDATE USING policies and
> ON CONFLICT UPDATE clauses. I think the argument against filtering is
> that the rows returned would then be misleading about what was
> actually updated.
It seems to me that it would be a horribly bad
On 11 September 2015 at 15:20, Stephen Frost wrote:
> * Dean Rasheed (dean.a.rash...@gmail.com) wrote:
>> I think blind updates are a pretty niche case, and I think that it
>> wasn't the intention to support them, but more of an unintentional
>> side effect of the implementation. That said, there
* Dean Rasheed (dean.a.rash...@gmail.com) wrote:
> I think blind updates are a pretty niche case, and I think that it
> wasn't the intention to support them, but more of an unintentional
> side effect of the implementation. That said, there are
> just-about-plausible use-cases where they might be c
On 11 September 2015 at 13:05, Robert Haas wrote:
> Thanks for the updates. My thoughts:
>
> On RETURNING, it seems like we've got a fairly fundamental problem
> here. If I understand correctly, the intention of allowing policies
> to be filtered by command type is to allow blind updates and del
Robert,
* Robert Haas (robertmh...@gmail.com) wrote:
> On Fri, Sep 11, 2015 at 7:33 AM, Stephen Frost wrote:
> > I've updated the page to add more details about the various items,
> > though the only code changes at this point considered 'open' are this
> > refactoring and the question regarding
On Fri, Sep 11, 2015 at 7:33 AM, Stephen Frost wrote:
> I've updated the page to add more details about the various items,
> though the only code changes at this point considered 'open' are this
> refactoring and the question regarding the 'row-level-security disabled'
> context which I posted a p
Dean,
* Dean Rasheed (dean.a.rash...@gmail.com) wrote:
> On 10 September 2015 at 21:48, Robert Haas wrote:
> > The open items list here:
> >
> > https://wiki.postgresql.org/wiki/PostgreSQL_9.5_Open_Items
> >
> > Dean's latest round of RLS refactoring.
>
> This refactoring patch doesn't fix any b
On 10 September 2015 at 21:48, Robert Haas wrote:
> The open items list here:
>
> https://wiki.postgresql.org/wiki/PostgreSQL_9.5_Open_Items
>
> Dean's latest round of RLS refactoring.
This refactoring patch doesn't fix any behavioural issues. It is all
about trying to make the code simpler and m
The open items list here:
https://wiki.postgresql.org/wiki/PostgreSQL_9.5_Open_Items
...currently has the following items related to RLS:
CREATE POLICY and RETURNING
Arguable RLS security bug, EvalPlanQual() paranoia
Dean's latest round of RLS refactoring.
more RLS oversights
Those items don't
31 matches
Mail list logo