On Sat, Sep 27, 2014 at 1:19 PM, Dean Rasheed <dean.a.rasheed@gmail.com> wrote:
>> 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.
Wait, what?
I think it's clear that the right thing to report would be the columns
that the user had permission to see via the view. The decision as to
what is visible in the error message has to be consistent with the
underlying permissions structure. Removing the detail altogether is
OK security-wise because it's just a subset of what the user can be
allowed to see, but I think checking the table permissions can never
be right.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
