[
https://issues.apache.org/jira/browse/IMPALA-10122?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17193702#comment-17193702
]
ASF subversion and git services commented on IMPALA-10122:
----------------------------------------------------------
Commit e8251bb09316d1cea04502b5de8516bc879fd7d3 in impala's branch
refs/heads/master from Fang-Yu Rao
[ https://gitbox.apache.org/repos/asf?p=impala.git;h=e8251bb ]
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 <[email protected]>
Tested-by: Impala Public Jenkins <[email protected]>
> Allow view authorization to be deferred until selection time
> ------------------------------------------------------------
>
> Key: IMPALA-10122
> URL: https://issues.apache.org/jira/browse/IMPALA-10122
> Project: IMPALA
> Issue Type: New Feature
> Components: Frontend
> Reporter: Fang-Yu Rao
> Assignee: Fang-Yu Rao
> Priority: Major
>
> Recall that currently Impala performs authorization with Ranger to check
> whether the requesting user is granted the privilege of {{SELECT}} for the
> underlying tables when a view is created and thus does not check whether the
> requesting user is granted the {{SELECT}} privilege on the underlying tables
> when the view is selected.
> On the other hand, currently a Spark user is not allowed to directly create a
> view in HMS without involving the Impala frontend, because Spark clients are
> normal users (v.s. superusers). To relax this restriction, it would be good
> to allow a Spark user to directly create a view in HMS without involving the
> Impala frontend. However, it can be seen that the authorization check is
> skipped for views created in this manner since HMS currently does not possess
> the capability to perform the authorization. Due to this relaxation, for a
> view created this way, the authorization of the view needs to be carried out
> at the selection time to make sure the requesting user is indeed granted the
> {{SELECT}} privileges on the underlying tables defined in the view.
> There is also a corresponding Hive JIRA at HIVE-24026. Refer to there for
> further details.
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
