* Robert Haas (robertmhaas@gmail.com) wrote:
> 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.
What I believe Dean was getting at is that if the user has direct
permissions on the underlying table then they could see the row by
querying the table directly too, so it'd be alright to report the detail
in the error. He then further points out that you're not likely to be
using a view over top of a table which you have direct access to, so
this is not a very interesting case.
In the end, it sounds like we all agree that the right approach is to
simply remove this detail and avoid the issue entirely.
Thanks,
Stephen