[
https://issues.apache.org/jira/browse/IMPALA-10505?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Fang-Yu Rao updated IMPALA-10505:
---------------------------------
Description:
We found that misleading audit logs could be generated in Impala if a
requesting user granted the privileges on a view does not have the privileges
on the table(s) on which the view is based. Such an issue could be reproduced
as follows.
# Start an authorization-enabled Impala cluster.
# As the user {{admin}}, execute "{{CREATE VIEW
default.v_functional_alltypestiny AS SELECT id, bool_col FROM
functional.alltypestiny;}}".
# As the user {{admin}}, execute "{{GRANT SELECT ON TABLE
default.v_functional_alltypestiny TO USER non_owner;}}".
# As the user {{admin}}, execute "{{REFRESH AUTHORIZATION;}}".
# Add a break point at
[RangerBufferAuditHandler#flush()|https://github.com/apache/impala/blob/aeeff53e884a67ee7f5980654a1d394c6e3e34ac/fe/src/main/java/org/apache/impala/authorization/ranger/RangerBufferAuditHandler.java#L122]
to observe the {{AuthzZuditEvent}}'s added to '{{auditEvents_}}' after the
following statement.
# As the user {{non_owner}}, execute "{{SELECT COUNT(\*) FROM
default.v_functional_alltypestiny;}}"
We will find that only 1 {{AuthzZuditEvent}} was logged. Specifically, the
field of '{{resourcePath}}' is "{{functional/alltypestiny}}" and the field of
'{{accessResult}}' is 0, indicating this is a failed authorization for the
underlying table of the view. But actually the user '{{non_owner}}' is and
should be allowed to execute the statement since it was granted the privilege
on the view.
Therefore, we should remove such a confusing log entry and also retain the
audit log entry corresponding to the privilege check for the view, i.e.,
{{default.v_functional_alltypestiny}}.
I have the following findings after an initial investigation.
Under the hood Impala performed 2 privileges checks. One for the view and the
other for the table on which the view is based. Since the user has been granted
the {{SELECT}} privilege on the view, the first privilege check would succeed,
whereas the second privilege check would fail since the user does not have the
{{SELECT}} privilege on the underlying table.
Each privilege check resulted in one audit log entry generated by the Ranger
server. Thus the first audit log entry would be a successful audit event
because it corresponds to the privilege check for the view. However, the second
privilege check resulted in a failed audit event since it corresponds to the
privilege check for the underlying table and the requesting user does not have
the {{SELECT}} privilege on the table. Impala performed the 2nd check for a
reason. In short, the requesting user is not allowed to access the runtime
profile if the user does not have the privileges on the underlying table(s).
Refer to
[BaseAuthorizationChecker#authorize()|https://github.com/apache/impala/blob/aeeff53e884a67ee7f5980654a1d394c6e3e34ac/fe/src/main/java/org/apache/impala/authorization/BaseAuthorizationChecker.java#L175-L190]
for further details.
On the other hand, for a list of audit events resulting from a query, if there
exists a failed audit event, only the first failed audit event would be kept by
Impala and then sent to Ranger. That is the reason why in the end we only saw
that failed audit event.
was:
We found that misleading audit logs could be generated in Impala if a
requesting user granted the privileges on a view does not have the privileges
on the table(s) on which the view is based. Such an issue could be reproduced
as follows.
# Start an authorization-enabled Impala cluster.
# As the user {{admin}}, execute "{{CREATE VIEW
default.v_functional_alltypestiny AS SELECT id, bool_col FROM
functional.alltypestiny;}}".
# As the user {{admin}}, execute "{{GRANT SELECT ON TABLE
default.v_functional_alltypestiny TO USER non_owner;}}".
# As the user {{admin}}, execute "{{REFRESH AUTHORIZATION;}}".
# Add a break point at
[RangerBufferAuditHandler#flush()|https://github.com/apache/impala/blob/aeeff53e884a67ee7f5980654a1d394c6e3e34ac/fe/src/main/java/org/apache/impala/authorization/ranger/RangerBufferAuditHandler.java#L122]
to observe the {{AuthzZuditEvent}}'s added to '{{auditEvents_}}' after the
following statement.
# As the user {{non_owner}}, execute "{{SELECT COUNT(\*) FROM
default.v_functional_alltypestiny;}}"
We will find that only 1 AuthzZuditEvent was logged. Specifically, the field of
'{{resourcePath}}' is "{{functional/alltypestiny}}" and the field of
'{{accessResult}}' is 0, indicating this is a failed authorization for the
underlying table of the view. But actually the user '{{non_owner}}' is and
should be allowed to execute the statement since it was granted the privilege
on the view.
Therefore, we should remove such a confusing log entry and also retain the
audit log entry corresponding to the privilege check for the view, i.e.,
{{default.v_functional_alltypestiny}}.
I have the following findings after an initial investigation.
Under the hood Impala performed 2 privileges checks. One for the view and the
other for the table on which the view is based. Since the user has been granted
the {{SELECT}} privilege on the view, the first privilege check would succeed,
whereas the second privilege check would fail since the user does not have the
{{SELECT}} privilege on the underlying table.
Each privilege check resulted in one audit log entry generated by the Ranger
server. Thus the first audit log entry would be a successful audit event
because it corresponds to the privilege check for the view. However, the second
privilege check resulted in a failed audit event since it corresponds to the
privilege check for the underlying table and the requesting user does not have
the {{SELECT}} privilege on the table. Impala performed the 2nd check for a
reason. In short, the requesting user is not allowed to access the runtime
profile if the user does not have the privileges on the underlying table(s).
Refer to
[BaseAuthorizationChecker#authorize()|https://github.com/apache/impala/blob/aeeff53e884a67ee7f5980654a1d394c6e3e34ac/fe/src/main/java/org/apache/impala/authorization/BaseAuthorizationChecker.java#L175-L190]
for further details.
On the other hand, for a list of audit events resulting from a query, if there
exists a failed audit event, only the first failed audit event would be kept by
Impala and then sent to Ranger. That is the reason why in the end we only saw
that failed audit event.
> Avoid creating misleading audit logs when a requesting user does not have
> privileges on the underlying tables of a view
> -----------------------------------------------------------------------------------------------------------------------
>
> Key: IMPALA-10505
> URL: https://issues.apache.org/jira/browse/IMPALA-10505
> Project: IMPALA
> Issue Type: Bug
> Reporter: Fang-Yu Rao
> Assignee: Fang-Yu Rao
> Priority: Major
>
> We found that misleading audit logs could be generated in Impala if a
> requesting user granted the privileges on a view does not have the privileges
> on the table(s) on which the view is based. Such an issue could be reproduced
> as follows.
> # Start an authorization-enabled Impala cluster.
> # As the user {{admin}}, execute "{{CREATE VIEW
> default.v_functional_alltypestiny AS SELECT id, bool_col FROM
> functional.alltypestiny;}}".
> # As the user {{admin}}, execute "{{GRANT SELECT ON TABLE
> default.v_functional_alltypestiny TO USER non_owner;}}".
> # As the user {{admin}}, execute "{{REFRESH AUTHORIZATION;}}".
> # Add a break point at
> [RangerBufferAuditHandler#flush()|https://github.com/apache/impala/blob/aeeff53e884a67ee7f5980654a1d394c6e3e34ac/fe/src/main/java/org/apache/impala/authorization/ranger/RangerBufferAuditHandler.java#L122]
> to observe the {{AuthzZuditEvent}}'s added to '{{auditEvents_}}' after the
> following statement.
> # As the user {{non_owner}}, execute "{{SELECT COUNT(\*) FROM
> default.v_functional_alltypestiny;}}"
> We will find that only 1 {{AuthzZuditEvent}} was logged. Specifically, the
> field of '{{resourcePath}}' is "{{functional/alltypestiny}}" and the field of
> '{{accessResult}}' is 0, indicating this is a failed authorization for the
> underlying table of the view. But actually the user '{{non_owner}}' is and
> should be allowed to execute the statement since it was granted the privilege
> on the view.
> Therefore, we should remove such a confusing log entry and also retain the
> audit log entry corresponding to the privilege check for the view, i.e.,
> {{default.v_functional_alltypestiny}}.
> I have the following findings after an initial investigation.
> Under the hood Impala performed 2 privileges checks. One for the view and the
> other for the table on which the view is based. Since the user has been
> granted the {{SELECT}} privilege on the view, the first privilege check would
> succeed, whereas the second privilege check would fail since the user does
> not have the {{SELECT}} privilege on the underlying table.
> Each privilege check resulted in one audit log entry generated by the Ranger
> server. Thus the first audit log entry would be a successful audit event
> because it corresponds to the privilege check for the view. However, the
> second privilege check resulted in a failed audit event since it corresponds
> to the privilege check for the underlying table and the requesting user does
> not have the {{SELECT}} privilege on the table. Impala performed the 2nd
> check for a reason. In short, the requesting user is not allowed to access
> the runtime profile if the user does not have the privileges on the
> underlying table(s). Refer to
> [BaseAuthorizationChecker#authorize()|https://github.com/apache/impala/blob/aeeff53e884a67ee7f5980654a1d394c6e3e34ac/fe/src/main/java/org/apache/impala/authorization/BaseAuthorizationChecker.java#L175-L190]
> for further details.
> On the other hand, for a list of audit events resulting from a query, if
> there exists a failed audit event, only the first failed audit event would be
> kept by Impala and then sent to Ranger. That is the reason why in the end we
> only saw that failed audit event.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-all-unsubscr...@impala.apache.org
For additional commands, e-mail: issues-all-h...@impala.apache.org
