Dean Rasheed <dean.a.rash...@gmail.com> writes:
> On 11 September 2015 at 15:49, Tom Lane <t...@sss.pgh.pa.us> 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 this would be a nothing-happens result not a
>> throw-error result, else you still leak info about the existence of
>> the row.
> That's what I was suggesting, except I was advocating a throw-error
> result rather than a nothing-happens result.
> Regarding the possibility of leaking info about the existence of rows,
> that's something that already happens with INSERT if there are unique
> indexes, and we've effectively decided there is nothing we can do
> about it. So I don't buy that as an argument for doing nothing over
> throwing an error.
Well, I don't buy your argument either. The unique-index problem means
that if you have INSERT or UPDATE privilege, you can check for existence
of a row conflicting with a row that RLS would let you insert or update.
It does not mean that DELETE privilege would let you make that check.
Also, the unique-index problem only applies if there's a relevant unique
index, which doesn't necessarily have anything at all to do with the RLS
filter condition.
I think this is coming back to Robert's concern, that it is far from clear
that we understand the interactions of per-command RLS policies well
enough to ship them. Maybe we should rip that out for 9.5 and only allow
a single RLS policy that that's the same for all commands. We can always
add the more general facility later.
> 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 understand your concern about that, and it's reasonable. But that
just leads me to the conclusion that maybe our ideas in this area are
not fully baked.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
