commit 09bed366fe7e681108f164ee53433b791dada90a
author Fang-Yu Rao <fangyu.rao@cloudera.com> Tue Oct 21 17:24:10 2025 -0700
committer Csaba Ringhofer <csringhofer@cloudera.com> Fri Feb 06 09:17:00 2026 +0000
tree 3ec3a3506b56bd321ed85e61e0f0d8684be90132
parent 39daf930d8badf47752d719bbcc27782f5680bbc

IMPALA-14507: Register column-level privilege requests for INSERT

This patch registers column-level privilege requests for columns
involved in the INSERT statement so that the requesting user does not
need to be granted the INSERT privilege on the entire table. This would
be helpful in the case when different users are allowed to insert data
into different sets of columns in the same table. Moreover, column-level
Ranger audit events for INSERT requests will be produced after this
patch.

This would also allow an administrator to add deny policies on columns
against a user if we would like to prevent the user from inserting data
into the specified columns.

On the other hand, this patch slightly revises the Preconditions checks
in BaseAuthorizationChecker#authorize() so that it is easier to
understand what those checks verify. The code comment there explicitly
mentions that for a statement that may produce several hierarchical
privilege requests, it should always have a corresponding table-level
privilege request if it has a column-level privilege request. This was
not entirely true and could not be detected by the previous checks.
Specifically, for the CREATE TABLE <db>.<target_tbl> AS SELECT
statement, we would register an ANY privilege request for the column
with wildcard table and column names denoting any column and table in
the database the target table belongs, i.e., '<db>.*.*', whereas there
was no privilege request for the table '<db>.*' registered. This patch
corrects this by registering an ANY privilege request for the database
of the target table instead. Due to this, we also changed the expected
error messages for some Java and end-to-end authorization-related tests.
This should not affect the security in that the resulting
RangerResourceImpl sent to the Ranger plug-in is the same whether the
privilege request is an ANY privilege request for the wildcard column
'<db>.*.*' or an ANY privilege request for the database '<db>'. Refer to
RangerAuthorizationChecker#authorizeResource() for more details.

Testing:
 - Added frontend and end-to-end tests to verify that
   a) we register column-level privilege requests in the INSERT
      statement in addition to the table-level one,
   b) a user is not allowed to insert data into a column of a table
      if there is a deny policy defined on the column against the user,
      even though the user was already granted the INSERT privilege on
      the table,
   c) a user is not allowed to insert data into a column if there is a
      column masking policy defined on any column of the same table,
      even though the user was already granted the INSERT privilege on
      the table (RANGER-1087 and IMPALA-10554),
   d) a user is allowed to insert data into a set of columns of a table
      as long as the user was granted the INSERT privileges on those
      columns given that there is no deny policy on those columns and
      no column masking policy on any column of the same table,
   e) column-level Ranger audit events could be produced after the
      introduction of column-level INSERT privilege,
   f) we are able to grant, revoke column-level INSERT privileges via
      the catalog server, and show column-level INSERT privileges via a
      coordinator.

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