]> granicus.if.org Git - postgresql/commit
Fix enforcement of SELECT FOR UPDATE permissions with nested views.
authorTom Lane <tgl@sss.pgh.pa.us>
Sat, 14 Apr 2018 19:38:09 +0000 (15:38 -0400)
committerTom Lane <tgl@sss.pgh.pa.us>
Sat, 14 Apr 2018 19:38:09 +0000 (15:38 -0400)
commit50c6bb022475bd9ad9c73e3b68b5152db5163b22
tree1fe5878ab68f336233b8e1f18c34a8208155f276
parent2a67d6440db4360efff2078a05bc172ca8f34b2b
Fix enforcement of SELECT FOR UPDATE permissions with nested views.

SELECT FOR UPDATE on a view should require UPDATE (as well as SELECT)
permissions on the view, and then the view's owner needs those same
permissions against the relations it references, and so on all the way
down to base tables.  But ApplyRetrieveRule did things in the wrong order,
resulting in failure to mark intermediate view levels as needing UPDATE
permission.  Thus for example, if user A creates a table T and an updatable
view V1 on T, then grants only SELECT permissions on V1 to user B, B could
create a second view V2 on V1 and then would be allowed to perform SELECT
FOR UPDATE via V2 (since V1 wouldn't be checked for UPDATE permissions).

To fix, just switch the order of expanding sub-views and marking referenced
objects as needing UPDATE permission.  I think additional simplifications
are now possible, but that's distinct from the bug fix proper.

This is certainly a security issue, but the consequences are pretty minor
(just the ability to lock rows that shouldn't be lockable).  Against that
we have a small risk of breaking applications that are working as-desired,
since nested views have behaved this way since such cases worked at all.
On balance I'm inclined not to back-patch.

Per report from Alexander Lakhin.

Discussion: https://postgr.es/m/24db7b8f-3de5-e25f-7ab9-d8848351d42c@gmail.com
src/backend/rewrite/rewriteHandler.c
src/test/regress/expected/updatable_views.out
src/test/regress/sql/updatable_views.sql