On Mon, Sep 29, 2014 at 10:26 AM, Stephen Frost <sfr...@snowman.net> wrote: > * Robert Haas (robertmh...@gmail.com) wrote: >> On Sat, Sep 27, 2014 at 1:19 PM, Dean Rasheed <dean.a.rash...@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.
Hmm, yeah. True. > 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. Well, I think that's an acceptable approach from the point of view of fixing the security exposure, but it's far from ideal. Good error messages are important for usability. I can live with this as a short-term fix, but in the long run I strongly believe we should try to do better. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
