On 27 September 2014 14:33, Stephen Frost <sfrost@snowman.net> wrote:
>> Yeah, I take that back. If there is a composite key involved then you
>> can run into the same issue- you update one of the columns to a
>> conflicting value and get back the entire key, including columns you
>> shouldn't be allowed to see.
>
> Alright, attached is a patch which addresses this by checking if the
> user has SELECT rights on the relation first and, if so, the existing
> error message is returned with the full row as usual, but if not, then
> the row data is omitted.
>
Seems reasonable.
> Also attached is a patch for 9.4 which does the same, but also removes
> the row reporting (completely) from the WITH CHECK case. It could be
> argued that it would be helpful to have it there also, perhaps, but I'm
> not convinced at this point that it's really valuable- and we'd have to
> think about how this would work with views (permission on the view? or
> on the table underneath? what if there is more than one?, etc).
>
Well by that point in the code, the query has been rewritten and the
row being reported is for the underlying table, so it's the table's
ACLs that should apply. In fact not all the values from the table are
even necessarily exported in the view, so its ACLs are not appropriate
to the values being reported. I suspect that in many/most real-world
cases, the user will only have permissions on the view, not on the
underlying table, in which case it won't work anyway. So +1 for just
removing it.
Regards,
Dean