commit e8251bb09316d1cea04502b5de8516bc879fd7d3
author Fang-Yu Rao <fangyu.rao@cloudera.com> Wed Sep 02 11:05:30 2020 -0700
committer Impala Public Jenkins <impala-public-jenkins@cloudera.com> Thu Sep 10 11:57:41 2020 +0000
tree 0157985625c6fc50e2571a72d7513d63bfe57ecf
parent efc627d050caeb9947af2dfd3fc8a02236c44d0e

IMPALA-10122 (Part 1): Deny access to views not authorized at creation

After HIVE-24026, a non-superuser is allowed to create, alter, and drop
a view directly in the HiveMetaStore via a Spark client without the
Impala FE or the HiveServer2 being involved to perform the corresponding
authorization checks to see if the non-superuser possesses the required
privileges on the underlying tables. This opens up the possibility that
a non-superuser is able to replace the underlying tables referenced in a
view with some other tables even though this non-superuser does not
possess the necessary privileges on those tables substituting for the
tables originally referenced in the view.

Recall that currently when a user is requesting to select a view in
Impala, the Impala FE only requires that there is a Ranger policy
granting the requesting user the SELECT privilege on the view but not
the SELECT privileges on the underlying tables of the view. Therefore,
with the change of HIVE-24026, a non-superuser is able to access the
data in tables for which the permission was not granted through either
i) an ALTER VIEW statement, or ii) a DROP VIEW statement followed by a
CREATE VIEW statement given that there is already a Ranger policy
allowing this user to select this view.

To prevent a user from accessing the data in tables on which the user
does not possess the required privileges, we could employ the Boolean
table property of 'Authorized' that was introduced in HIVE-24026.
Specifically, after HIVE-24026, if a view was created without the
corresponding privileges on the underlying tables being checked, the
HiveMetaStore would set this property to false and the property will not
be added if the view was authorized at creation time for backward
compatibility. Based on this table property, it is possible for the
Impala FE to determine whether or not it should additionally check for
the requesting user's privileges on the underlying tables of a view
after HIVE-24026 at selection time, but it would require a more thorough
investigation regarding how to revise the way the Impala FE registers
the authorization requests given a query.

To mitigate this potential security breach before we figure out how to
perform authorization for a view whose creation was not authorized, in
this patch, we introduce a temporary field of 'viewCreatedWithoutAuthz_'
in the class of AuthorizableTable that indicates whether or not a given
table corresponds to a view that was not authorized at creation time,
allowing the Impala FE to deny the SELECT, ALTER, and DESCRIBE access to
a view whose creation was not authorized.

Testing:
 - Manually verified that after using beeline to set to false the table
   property of 'Authorized' corresponding to a view, no user is able to
   select data from this view, or to alter or describe this view. Recall
   that currently Impala does not support the ALTER VIEW SET
   TBLPROPERTIES statement and thus we need to use beeline to create
   such a view.
 - Verified that the patch could pass the exhaustive tests in the DEBUG
   build.

Change-Id: I73965e05586771de85fa6f73c452e3de4f312034
Reviewed-on: http://gerrit.cloudera.org:8080/16423
Reviewed-by: Quanlong Huang <huangquanlong@gmail.com>
Tested-by: Impala Public Jenkins <impala-public-jenkins@cloudera.com>