You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues-all@impala.apache.org by "Fang-Yu Rao (Jira)" <ji...@apache.org> on 2022/05/20 21:28:00 UTC

[jira] [Commented] (IMPALA-10300) Investigate the need for checking the privilege on server when creating a Kudu table with property of kudu.master_addresses

    [ https://issues.apache.org/jira/browse/IMPALA-10300?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17540305#comment-17540305 ] 

Fang-Yu Rao commented on IMPALA-10300:
--------------------------------------

In general a user should not need to explicitly specify the table property of '{{{}kudu.master_addresses{}}}' in a query if this piece of information could be passed to Impala when the Impala service was started via the flag of '{{{}-kudu_master_hosts{}}}'. Refer to [https://github.com/apache/impala/blob/master/be/src/service/frontend.cc#L82-L84].

So always providing Impala with the addresses of Kudu master(s) when Impala is started is a better practice in that a user does not have to include the table property of '{{{}kudu.master_addresses{}}}', which would override whatever default Kudu master address(es) that was (were) passed to Impala during the startup. Refer to [https://github.com/apache/impala/blob/master/fe/src/main/java/org/apache/impala/analysis/CreateTableStmt.java#L409-L415].

On the other hand, if a user tries to create a Kudu table on the *non-default* Kudu master nodes, then requiring the requesting user to have the {{ALL}} privilege on the Impala service should be reasonable. Lowering the privilege requirement in such a case would make Impala less secure.

Based on the analysis above, this JIRA is not really an issue.

> Investigate the need for checking the privilege on server when creating a Kudu table with property of kudu.master_addresses
> ---------------------------------------------------------------------------------------------------------------------------
>
>                 Key: IMPALA-10300
>                 URL: https://issues.apache.org/jira/browse/IMPALA-10300
>             Project: IMPALA
>          Issue Type: Improvement
>          Components: Frontend
>            Reporter: Fang-Yu Rao
>            Assignee: Fang-Yu Rao
>            Priority: Major
>
> We found that based on the default Ranger policies loaded by {{$IMPALA_HOME/testdata/bin/create-load-data.sh}}, the following query would result in an {{AuthorizationException}}.
> {noformat}
> CREATE TABLE `kudu_table` (
> `id` BIGINT,
> `name` STRING, primary key(id)
> )
> STORED AS KUDU
> TBLPROPERTIES(
>   'kudu.master_addresses' = 'localhost'
> );
> {noformat}
> According to the error message, the requesting user does not have the necessary privileges on "{{server1}}", where "{{server1}}" is part of the input arguments we use to start {{impalad}}'s and {{catalogd}} in an authorization-enabled cluster.
> However, if we do not explicitly add the table property of '{{kudu.master_addresses}}', the query could be performed without any error and the result returned for the query of "{{SHOW CREATE TABLE kudu_table}}" would still contain the property of "{{'kudu.master_addresses'='localhost'}}".
> Hence, it would be good to figure out whether the check of the privileges on {{server1}} is really necessary and whether the check could be waived if the explicitly specified 'kudu.master_addresses' happens to be the default value, i.e., "localhost" in this case. Notice that in order for a query with an explicitly specified '{{kudu.master_addresses}}' property, we have to add the requesting user in the the policies of 1) {{all - database, table, column}}, 2) {{all - database, udf}}, and 3) {{all - url}}, which seems to grant too many privileges than necessary to the requesting user since in this case, the requesting user would be able to perform any operations on {{server1}} in Impala.



--
This message was sent by Atlassian Jira
(v8.20.7#820007)

---------------------------------------------------------------------
To unsubscribe, e-mail: issues-all-unsubscribe@impala.apache.org
For additional commands, e-mail: issues-all-help@impala.apache.org