You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@impala.apache.org by to...@apache.org on 2018/09/06 23:01:57 UTC
[3/4] impala git commit: [DOCS] Additional updates to the
fine-grained priv
[DOCS] Additional updates to the fine-grained priv
Change-Id: I964a34a4a5a94d88bb09f66e7b0d25fe5b4d6d7c
Reviewed-on: http://gerrit.cloudera.org:8080/11386
Tested-by: Impala Public Jenkins <im...@cloudera.com>
Reviewed-by: Adam Holley <ah...@cloudera.com>
Reviewed-by: Alex Rodoni <ar...@cloudera.com>
Project: http://git-wip-us.apache.org/repos/asf/impala/repo
Commit: http://git-wip-us.apache.org/repos/asf/impala/commit/0acf1b3a
Tree: http://git-wip-us.apache.org/repos/asf/impala/tree/0acf1b3a
Diff: http://git-wip-us.apache.org/repos/asf/impala/diff/0acf1b3a
Branch: refs/heads/master
Commit: 0acf1b3a94c874f11508972d1d873969a74e5a20
Parents: b986f2a
Author: Alex Rodoni <ar...@cloudera.com>
Authored: Tue Sep 4 16:26:55 2018 -0700
Committer: Alex Rodoni <ar...@cloudera.com>
Committed: Thu Sep 6 03:28:21 2018 +0000
----------------------------------------------------------------------
docs/shared/impala_common.xml | 13 +-
docs/topics/impala_authorization.xml | 721 +++++++++++++++++++-----------
docs/topics/impala_grant.xml | 91 ++--
docs/topics/impala_revoke.xml | 91 ++--
4 files changed, 569 insertions(+), 347 deletions(-)
----------------------------------------------------------------------
http://git-wip-us.apache.org/repos/asf/impala/blob/0acf1b3a/docs/shared/impala_common.xml
----------------------------------------------------------------------
diff --git a/docs/shared/impala_common.xml b/docs/shared/impala_common.xml
index 9d103c2..c414b9c 100644
--- a/docs/shared/impala_common.xml
+++ b/docs/shared/impala_common.xml
@@ -127,9 +127,10 @@ under the License.
<codeph>INSERT</codeph>, <codeph>CREATE</codeph>,
<codeph>ALTER</codeph>, <codeph>DROP</codeph>, <b><i>and</i></b>
<codeph>REFRESH</codeph> privileges.</li>
- <li>The parent levels of the specified scope are implicitly supported.
- For example, if a privilege is listed with the
- <codeph>TABLE</codeph> scope, the same privilege granted on
+ <li>The parent levels of the specified scope are implicitly supported
+ where a scope refers to the specific level in the object hierarchy
+ that the privilege is granted. For example, if a privilege is listed
+ with the <codeph>TABLE</codeph> scope, the same privilege granted on
<codeph>DATABASE</codeph> and <codeph>SERVER</codeph> will allow
the user to execute the specified SQL statement.</li>
</ul><table id="sentry_privileges_objects_tab" frame="all" colsep="1"
@@ -405,6 +406,12 @@ under the License.
<entry>TABLE</entry>
</row>
<row>
+ <entry>If the user has the SELECT privilege at the COLUMN level,
+ only the columns the user has access will show.</entry>
+ <entry>SELECT</entry>
+ <entry>COLUMN</entry>
+ </row>
+ <row>
<entry>USE</entry>
<entry>ANY</entry>
<entry>TABLE</entry>
http://git-wip-us.apache.org/repos/asf/impala/blob/0acf1b3a/docs/topics/impala_authorization.xml
----------------------------------------------------------------------
diff --git a/docs/topics/impala_authorization.xml b/docs/topics/impala_authorization.xml
index 6e63d27..b3317c2 100644
--- a/docs/topics/impala_authorization.xml
+++ b/docs/topics/impala_authorization.xml
@@ -21,6 +21,7 @@ under the License.
<concept rev="1.1" id="authorization">
<title>Enabling Sentry Authorization for Impala</title>
+
<prolog>
<metadata>
<data name="Category" value="Security"/>
@@ -37,25 +38,29 @@ under the License.
<conbody id="sentry">
<p>
- Authorization determines which users are allowed to access which resources, and what operations they are
- allowed to perform. In Impala 1.1 and higher, you use Apache Sentry for
- authorization. Sentry adds a fine-grained authorization framework for Hadoop. By default (when authorization
- is not enabled), Impala does all read and write operations with the privileges of the <codeph>impala</codeph>
- user, which is suitable for a development/test environment but not for a secure production environment. When
- authorization is enabled, Impala uses the OS user ID of the user who runs <cmdname>impala-shell</cmdname> or
- other client program, and associates various privileges with each user.
+ Authorization determines which users are allowed to access which resources, and what
+ operations they are allowed to perform. In Impala 1.1 and higher, you use Apache Sentry
+ for authorization. Sentry adds a fine-grained authorization framework for Hadoop. By
+ default (when authorization is not enabled), Impala does all read and write operations
+ with the privileges of the <codeph>impala</codeph> user, which is suitable for a
+ development/test environment but not for a secure production environment. When
+ authorization is enabled, Impala uses the OS user ID of the user who runs
+ <cmdname>impala-shell</cmdname> or other client program, and associates various privileges
+ with each user.
</p>
<note>
- Sentry is typically used in conjunction with Kerberos authentication, which defines which hosts are allowed
- to connect to each server. Using the combination of Sentry and Kerberos prevents malicious users from being
- able to connect by creating a named account on an untrusted machine. See
- <xref href="impala_kerberos.xml#kerberos"/> for details about Kerberos authentication.
+ Sentry is typically used in conjunction with Kerberos authentication, which defines which
+ hosts are allowed to connect to each server. Using the combination of Sentry and Kerberos
+ prevents malicious users from being able to connect by creating a named account on an
+ untrusted machine. See <xref href="impala_kerberos.xml#kerberos"/> for details about
+ Kerberos authentication.
</note>
<p audience="PDF" outputclass="toc inpage">
See the following sections for details about using the Impala authorization features:
</p>
+
</conbody>
<concept id="sentry_priv_model">
@@ -81,20 +86,27 @@ under the License.
Table
Column
</codeblock>
- <p rev="2.3.0 collevelauth"> The table-level privileges apply to views as
- well. Anywhere you specify a table name, you can specify a view name
- instead. </p>
- <p rev="2.3.0 collevelauth"> In <keyword keyref="impala23_full"/> and
- higher, you can specify privileges for individual columns. </p>
+
+ <p rev="2.3.0 collevelauth">
+ The table-level privileges apply to views as well. Anywhere you specify a table name,
+ you can specify a view name instead.
+ </p>
+
+ <p rev="2.3.0 collevelauth">
+ In <keyword keyref="impala23_full"/> and higher, you can specify privileges for
+ individual columns.
+ </p>
<p conref="../shared/impala_common.xml#common/sentry_privileges_objects"/>
- <p> Originally, privileges were encoded in a policy file, stored in HDFS.
- This mode of operation is still an option, but the emphasis of privilege
- management is moving towards being SQL-based. The mode of operation with
- <codeph>GRANT</codeph> and <codeph>REVOKE</codeph> statements instead
- of the policy file requires that a special Sentry service be enabled;
- this service stores, retrieves, and manipulates privilege information
- stored inside the metastore database. </p>
+
+ <p>
+ Originally, privileges were encoded in a policy file, stored in HDFS. This mode of
+ operation is still an option, but the emphasis of privilege management is moving towards
+ being SQL-based. The mode of operation with <codeph>GRANT</codeph> and
+ <codeph>REVOKE</codeph> statements instead of the policy file requires that a special
+ Sentry service be enabled; this service stores, retrieves, and manipulates privilege
+ information stored inside the metastore database.
+ </p>
<note>
<p>
@@ -119,59 +131,68 @@ under the License.
</li>
</ul>
</note>
- <p> If you change privileges in Sentry, e.g. adding a user, removing a
- user, modifying privileges, you must clear the Impala Catalog server
- cache by running the <codeph>INVALIDATE METADATA</codeph> statement.
- <codeph>INVALIDATE METADATA</codeph> is not required if you make the
- changes to privileges within Impala. </p>
+
+ <p>
+ If you change privileges in Sentry, e.g. adding a user, removing a user, modifying
+ privileges, you must clear the Impala Catalog server cache by running the
+ <codeph>INVALIDATE METADATA</codeph> statement. <codeph>INVALIDATE METADATA</codeph> is
+ not required if you make the changes to privileges within Impala.
+ </p>
+
</conbody>
+
</concept>
<concept id="secure_startup">
<title>Starting the impalad Daemon with Sentry Authorization Enabled</title>
- <prolog>
- <metadata>
- <data name="Category" value="Starting and Stopping"/>
- </metadata>
- </prolog>
+
+ <prolog>
+ <metadata>
+ <data name="Category" value="Starting and Stopping"/>
+ </metadata>
+ </prolog>
<conbody>
<p>
- To run the <cmdname>impalad</cmdname> daemon with authorization enabled, you add one or more options to the
- <codeph>IMPALA_SERVER_ARGS</codeph> declaration in the <filepath>/etc/default/impala</filepath>
- configuration file:
+ To run the <cmdname>impalad</cmdname> daemon with authorization enabled, you add one or
+ more options to the <codeph>IMPALA_SERVER_ARGS</codeph> declaration in the
+ <filepath>/etc/default/impala</filepath> configuration file:
</p>
+
<ul>
<li>
- <codeph>-server_name</codeph>: Turns on Sentry authorization for
- Impala. The authorization rules refer to a symbolic server name, and
- you specify the same name to use as the argument to the
- <codeph>-server_name</codeph> option for all
- <cmdname>impalad</cmdname> nodes in the cluster. <p> Starting in
- Impala 1.4.0 and higher, if you specify just
- <codeph>-server_name</codeph> without
- <codeph>-authorization_policy_file</codeph>, Impala uses the
- Sentry service for authorization. </p>
+ <codeph>-server_name</codeph>: Turns on Sentry authorization for Impala. The
+ authorization rules refer to a symbolic server name, and you specify the same name to
+ use as the argument to the <codeph>-server_name</codeph> option for all
+ <cmdname>impalad</cmdname> nodes in the cluster.
+ <p>
+ Starting in Impala 1.4.0 and higher, if you specify just
+ <codeph>-server_name</codeph> without <codeph>-authorization_policy_file</codeph>,
+ Impala uses the Sentry service for authorization.
+ </p>
</li>
+
<li>
<codeph>-sentry_config</codeph>: Specifies the local path to the
- <codeph>sentry-site.xml</codeph> configuration file. This setting is
- required to enable authorization. </li>
+ <codeph>sentry-site.xml</codeph> configuration file. This setting is required to
+ enable authorization.
+ </li>
+
<li>
- <codeph>-authorization_policy_file</codeph>: Specifies the HDFS path
- to the policy file that defines the privileges on schema objects.
- Prior to Impala 1.4.0, or if you want to continue storing privilege
- rules in the policy file, specify the
- <codeph>-authorization_policy_file</codeph> option to make Impala
- read privilege information from a policy file, rather than from the
- metastore database. </li>
+ <codeph>-authorization_policy_file</codeph>: Specifies the HDFS path to the policy
+ file that defines the privileges on schema objects. Prior to Impala 1.4.0, or if you
+ want to continue storing privilege rules in the policy file, specify the
+ <codeph>-authorization_policy_file</codeph> option to make Impala read privilege
+ information from a policy file, rather than from the metastore database.
+ </li>
</ul>
<p rev="1.4.0">
- For example, you might adapt your <filepath>/etc/default/impala</filepath> configuration to contain lines
- like the following. To use the Sentry service rather than the policy file:
+ For example, you might adapt your <filepath>/etc/default/impala</filepath> configuration
+ to contain lines like the following. To use the Sentry service rather than the policy
+ file:
</p>
<codeblock rev="1.4.0">IMPALA_SERVER_ARGS=" \
@@ -196,96 +217,141 @@ under the License.
configuration file for Hive, as well as in the <codeph>-server_name</codeph> option for
<cmdname>impalad</cmdname>.
</p>
- <p> Now restart the <cmdname>impalad</cmdname> daemons on all the nodes. </p>
+
+ <p>
+ Now restart the <cmdname>impalad</cmdname> daemons on all the nodes.
+ </p>
+
</conbody>
+
</concept>
<concept id="sentry_service">
<title>Using Impala with the Sentry Service</title>
+
<conbody>
- <p> When you use the Sentry service, you set up privileges through the
- <codeph>GRANT</codeph> and <codeph>REVOKE</codeph> statements in
- either Impala or Hive. Then both components use those same privileges
- automatically. (Impala added the <codeph>GRANT</codeph> and
- <codeph>REVOKE</codeph> statements in <keyword keyref="impala20_full"
- />.) </p>
- <p> For information about using the Impala <codeph>GRANT</codeph> and
- <codeph>REVOKE</codeph> statements, see <xref
- href="impala_grant.xml#grant"/> and <xref
- href="impala_revoke.xml#revoke"/>. </p>
- <p> URIs represent the file paths you specify as part of statements such
- as <codeph>CREATE EXTERNAL TABLE</codeph> and <codeph>LOAD
- DATA</codeph>. Typically, you specify what look like UNIX paths, but
- these locations can also be prefixed with <codeph>hdfs://</codeph> to
- make clear that they are really URIs. To set privileges for a URI,
- specify the name of a directory, and the privilege applies to all the
- files in that directory and any directories underneath it. </p>
- <p> URIs must start with <codeph>hdfs://</codeph>,
- <codeph>s3a://</codeph>, <codeph>adl://</codeph>, or
- <codeph>file://</codeph>. If a URI starts with an absolute path, the
- path will be appended to the default filesystem prefix. For example, if
- you specify: <codeblock>
+
+ <p>
+ When you use the Sentry service, you set up privileges through the
+ <codeph>GRANT</codeph> and <codeph>REVOKE</codeph> statements in either Impala or Hive.
+ Then both components use those same privileges automatically. (Impala added the
+ <codeph>GRANT</codeph> and <codeph>REVOKE</codeph> statements in
+ <keyword keyref="impala20_full"
+ />.)
+ </p>
+
+ <p>
+ For information about using the Impala <codeph>GRANT</codeph> and
+ <codeph>REVOKE</codeph> statements, see <xref
+ href="impala_grant.xml#grant"/>
+ and <xref
+ href="impala_revoke.xml#revoke"/>.
+ </p>
+
+ <p>
+ URIs represent the file paths you specify as part of statements such as <codeph>CREATE
+ EXTERNAL TABLE</codeph> and <codeph>LOAD DATA</codeph>. Typically, you specify what look
+ like UNIX paths, but these locations can also be prefixed with <codeph>hdfs://</codeph>
+ to make clear that they are really URIs. To set privileges for a URI, specify the name
+ of a directory, and the privilege applies to all the files in that directory and any
+ directories underneath it.
+ </p>
+
+ <p>
+ URIs must start with <codeph>hdfs://</codeph>, <codeph>s3a://</codeph>,
+ <codeph>adl://</codeph>, or <codeph>file://</codeph>. If a URI starts with an absolute
+ path, the path will be appended to the default filesystem prefix. For example, if you
+ specify:
+<codeblock>
GRANT ALL ON URI '/tmp';
-</codeblock> The above
- statement effectively becomes the following where the default filesystem
- is HDFS.
- <codeblock>
+</codeblock>
+ The above statement effectively becomes the following where the default filesystem is
+ HDFS.
+<codeblock>
GRANT ALL ON URI 'hdfs://localhost:20500/tmp';
</codeblock>
</p>
- <p> When defining URIs for HDFS, you must also specify the NameNode. For
- example: <codeblock>GRANT ALL ON URI file:///path/to/dir TO <role>
+
+ <p>
+ When defining URIs for HDFS, you must also specify the NameNode. For example:
+<codeblock>GRANT ALL ON URI file:///path/to/dir TO <role>
GRANT ALL ON URI hdfs://namenode:port/path/to/dir TO <role></codeblock>
<note type="warning">
- <p> Because the NameNode host and port must be specified, it is
- strongly recommended that you use High Availability (HA). This
- ensures that the URI will remain constant even if the NameNode
- changes. For example: </p>
- <codeblock>GRANT ALL ON URI hdfs://ha-nn-uri/path/to/dir TO <role></codeblock>
+ <p>
+ Because the NameNode host and port must be specified, it is strongly recommended
+ that you use High Availability (HA). This ensures that the URI will remain constant
+ even if the NameNode changes. For example:
+ </p>
+<codeblock>GRANT ALL ON URI hdfs://ha-nn-uri/path/to/dir TO <role></codeblock>
</note>
</p>
+
</conbody>
+
</concept>
+
<concept id="concept_k45_lbm_f2b">
+
<title>Examples of Setting up Authorization for Security Scenarios</title>
+
<conbody>
- <p> The following examples show how to set up authorization to deal with
- various scenarios. </p>
+
+ <p>
+ The following examples show how to set up authorization to deal with various scenarios.
+ </p>
+
<example>
+
<title>A User with No Privileges</title>
- <p> If a user has no privileges at all, that user cannot access any
- schema objects in the system. The error messages do not disclose the
- names or existence of objects that the user is not authorized to read. </p>
- <p> This is the experience you want a user to have if they somehow log
- into a system where they are not an authorized Impala user. Or in a
- real deployment, a user might have no privileges because they are not
- a member of any of the authorized groups. </p>
+
+ <p>
+ If a user has no privileges at all, that user cannot access any schema objects in the
+ system. The error messages do not disclose the names or existence of objects that the
+ user is not authorized to read.
+ </p>
+
+ <p>
+ This is the experience you want a user to have if they somehow log into a system where
+ they are not an authorized Impala user. Or in a real deployment, a user might have no
+ privileges because they are not a member of any of the authorized groups.
+ </p>
+
</example>
+
<example>
+
<title>Examples of Privileges for Administrative Users</title>
- <p> In this example, the SQL statements grant the
- <codeph>entire_server</codeph> role all privileges on both the
- databases and URIs within the server. </p>
- <codeblock>CREATE ROLE entire_server;
+
+ <p>
+ In this example, the SQL statements grant the <codeph>entire_server</codeph> role all
+ privileges on both the databases and URIs within the server.
+ </p>
+
+<codeblock>CREATE ROLE entire_server;
GRANT ROLE entire_server TO GROUP admin_group;
GRANT ALL ON SERVER server1 TO ROLE entire_server;
</codeblock>
+
</example>
+
<example>
+
<title>A User with Privileges for Specific Databases and Tables</title>
- <p> If a user has privileges for specific tables in specific databases,
- the user can access those things but nothing else. They can see the
- tables and their parent databases in the output of <codeph>SHOW
- TABLES</codeph> and <codeph>SHOW DATABASES</codeph>,
- <codeph>USE</codeph> the appropriate databases, and perform the
- relevant actions (<codeph>SELECT</codeph> and/or
- <codeph>INSERT</codeph>) based on the table privileges. To actually
- create a table requires the <codeph>ALL</codeph> privilege at the
- database level, so you might define separate roles for the user that
- sets up a schema and other users or applications that perform
- day-to-day operations on the tables. </p>
- <codeblock>
+
+ <p>
+ If a user has privileges for specific tables in specific databases, the user can
+ access those things but nothing else. They can see the tables and their parent
+ databases in the output of <codeph>SHOW TABLES</codeph> and <codeph>SHOW
+ DATABASES</codeph>, <codeph>USE</codeph> the appropriate databases, and perform the
+ relevant actions (<codeph>SELECT</codeph> and/or <codeph>INSERT</codeph>) based on the
+ table privileges. To actually create a table requires the <codeph>ALL</codeph>
+ privilege at the database level, so you might define separate roles for the user that
+ sets up a schema and other users or applications that perform day-to-day operations on
+ the tables.
+ </p>
+
+<codeblock>
CREATE ROLE one_database;
GRANT ROLE one_database TO GROUP admin_group;
GRANT ALL ON DATABASE db1 TO ROLE one_database;
@@ -298,56 +364,87 @@ GRANT ALL ON TABLE db1.lesson TO ROLE instructor;
CREATE ROLE student;
GRANT ROLE student TO GROUP visitors;
GRANT SELECT ON TABLE db1.training TO ROLE student;</codeblock>
+
</example>
+
<example>
+
<title>Privileges for Working with External Data Files</title>
- <p> When data is being inserted through the <codeph>LOAD DATA</codeph>
- statement, or is referenced from an HDFS location outside the normal
- Impala database directories, the user also needs appropriate
- permissions on the URIs corresponding to those HDFS locations. </p>
- <p> In this example: </p>
+
+ <p>
+ When data is being inserted through the <codeph>LOAD DATA</codeph> statement, or is
+ referenced from an HDFS location outside the normal Impala database directories, the
+ user also needs appropriate permissions on the URIs corresponding to those HDFS
+ locations.
+ </p>
+
+ <p>
+ In this example:
+ </p>
+
<ul>
- <li> The <codeph>external_table</codeph> role can insert into and
- query the Impala table, <codeph>external_table.sample</codeph>. </li>
- <li> The <codeph>staging_dir</codeph> role can specify the HDFS path
- <filepath>/user/impala-user/external_data</filepath> with the
- <codeph>LOAD DATA</codeph> statement. When Impala queries or loads
- data files, it operates on all the files in that directory, not just
- a single file, so any Impala <codeph>LOCATION</codeph> parameters
- refer to a directory rather than an individual file. </li>
+ <li>
+ The <codeph>external_table</codeph> role can insert into and query the Impala table,
+ <codeph>external_table.sample</codeph>.
+ </li>
+
+ <li>
+ The <codeph>staging_dir</codeph> role can specify the HDFS path
+ <filepath>/user/impala-user/external_data</filepath> with the <codeph>LOAD
+ DATA</codeph> statement. When Impala queries or loads data files, it operates on all
+ the files in that directory, not just a single file, so any Impala
+ <codeph>LOCATION</codeph> parameters refer to a directory rather than an individual
+ file.
+ </li>
</ul>
- <codeblock>CREATE ROLE external_table;
+
+<codeblock>CREATE ROLE external_table;
GRANT ROLE external_table TO GROUP impala_users;
GRANT ALL ON TABLE external_table.sample TO ROLE external_table;
CREATE ROLE staging_dir;
GRANT ROLE staging TO GROUP impala_users;
GRANT ALL ON URI 'hdfs://127.0.0.1:8020/user/impala-user/external_data' TO ROLE staging_dir;</codeblock>
+
</example>
+
<example>
- <title>Separating Administrator Responsibility from Read and Write
- Privileges</title>
- <p> To create a database, you need the full privilege on that database
- while day-to-day operations on tables within that database can be
- performed with lower levels of privilege on specific table. Thus, you
- might set up separate roles for each database or application: an
- administrative one that could create or drop the database, and a
- user-level one that can access only the relevant tables. </p>
- <p> In this example, the responsibilities are divided between users in 3
- different groups: </p>
+
+ <title>Separating Administrator Responsibility from Read and Write Privileges</title>
+
+ <p>
+ To create a database, you need the full privilege on that database while day-to-day
+ operations on tables within that database can be performed with lower levels of
+ privilege on specific table. Thus, you might set up separate roles for each database
+ or application: an administrative one that could create or drop the database, and a
+ user-level one that can access only the relevant tables.
+ </p>
+
+ <p>
+ In this example, the responsibilities are divided between users in 3 different groups:
+ </p>
+
<ul>
- <li> Members of the <codeph>supergroup</codeph> group have the
- <codeph>training_sysadmin</codeph> role and so can set up a
- database named <codeph>training</codeph>. </li>
- <li> Members of the <codeph>impala_users</codeph> group have the
- <codeph>instructor</codeph> role and so can create, insert into,
- and query any tables in the <codeph>training</codeph> database, but
- cannot create or drop the database itself. </li>
- <li> Members of the <codeph>visitor</codeph> group have the
- <codeph>student</codeph> role and so can query those tables in the
- <codeph>training</codeph> database. </li>
+ <li>
+ Members of the <codeph>supergroup</codeph> group have the
+ <codeph>training_sysadmin</codeph> role and so can set up a database named
+ <codeph>training</codeph>.
+ </li>
+
+ <li>
+ Members of the <codeph>impala_users</codeph> group have the
+ <codeph>instructor</codeph> role and so can create, insert into, and query any
+ tables in the <codeph>training</codeph> database, but cannot create or drop the
+ database itself.
+ </li>
+
+ <li>
+ Members of the <codeph>visitor</codeph> group have the <codeph>student</codeph> role
+ and so can query those tables in the <codeph>training</codeph> database.
+ </li>
</ul>
- <codeblock>CREATE ROLE training_sysadmin;
+
+<codeblock>CREATE ROLE training_sysadmin;
GRANT ROLE training_sysadmin TO GROUP supergroup;
GRANT ALL ON DATABASE training1 TO ROLE training_sysadmin;
@@ -358,176 +455,258 @@ GRANT ALL ON TABLE training1.course1 TO ROLE instructor;
CREATE ROLE visitor;
GRANT ROLE student TO GROUP visitor;
GRANT SELECT ON TABLE training1.course1 TO ROLE student;</codeblock>
+
</example>
+
</conbody>
+
</concept>
+
<concept id="security_policy_file">
+
<title>Using Impala with the Sentry Policy File</title>
+
<conbody>
- <p> The policy file is a file that you put in a designated location in
- HDFS, and is read during the startup of the <cmdname>impalad</cmdname>
- daemon when you specify both the <codeph>-server_name</codeph> and
- <codeph>-authorization_policy_file</codeph> startup options. It
- controls which objects (databases, tables, and HDFS directory paths) can
- be accessed by the user who connects to <cmdname>impalad</cmdname>, and
- what operations that user can perform on the objects. </p>
- <note rev="1.4.0"> In <ph rev="upstream">CDH 5</ph> and higher, <ph
- rev="upstream">Cloudera</ph> recommends managing privileges through
- SQL statements, as described in <xref
- href="impala_authorization.xml#sentry_service"/>. If you are still
- using policy files, plan to migrate to the new approach some time in the
- future. </note>
- <p> The location of the policy file is listed in the
- <filepath>auth-site.xml</filepath> configuration file. </p>
- <p> When authorization is enabled, Impala uses the policy file as a
- <i>whitelist</i>, representing every privilege available to any user
- on any object. That is, only operations specified for the appropriate
- combination of object, role, group, and user are allowed. All other
- operations are not allowed. If a group or role is defined multiple times
- in the policy file, the last definition takes precedence. </p>
- <p> To understand the notion of whitelisting, set up a minimal policy file
- that does not provide any privileges for any object. When you connect to
- an Impala node where this policy file is in effect, you get no results
- for <codeph>SHOW DATABASES</codeph>, and an error when you issue any
- <codeph>SHOW TABLES</codeph>, <codeph>USE
- <varname>database_name</varname></codeph>, <codeph>DESCRIBE
- <varname>table_name</varname></codeph>, <codeph>SELECT</codeph>, and
- or other statements that expect to access databases or tables, even if
- the corresponding databases and tables exist. </p>
- <p> The contents of the policy file are cached, to avoid a performance
- penalty for each query. The policy file is re-checked by each
- <cmdname>impalad</cmdname> node every 5 minutes. When you make a
- non-time-sensitive change such as adding new privileges or new users,
- you can let the change take effect automatically a few minutes later. If
- you remove or reduce privileges, and want the change to take effect
- immediately, restart the <cmdname>impalad</cmdname> daemon on all nodes,
- again specifying the <codeph>-server_name</codeph> and
- <codeph>-authorization_policy_file</codeph> options so that the rules
- from the updated policy file are applied. </p>
+
+ <p>
+ The policy file is a file that you put in a designated location in HDFS, and is read
+ during the startup of the <cmdname>impalad</cmdname> daemon when you specify both the
+ <codeph>-server_name</codeph> and <codeph>-authorization_policy_file</codeph> startup
+ options. It controls which objects (databases, tables, and HDFS directory paths) can be
+ accessed by the user who connects to <cmdname>impalad</cmdname>, and what operations
+ that user can perform on the objects.
+ </p>
+
+ <note rev="1.4.0">
+ The policy-file based authorization was deprecated in <keyword keyref="impala26"/>. We
+ recommend managing privileges through SQL statements as described in
+ <xref
+ href="impala_authorization.xml#sentry_service"/>. If you are still using
+ policy files, plan to migrate to the new approach some time in the future.
+ </note>
+
+ <p>
+ The location of the policy file is listed in the <filepath>auth-site.xml</filepath>
+ configuration file.
+ </p>
+
+ <p>
+ When authorization is enabled, Impala uses the policy file as a <i>whitelist</i>,
+ representing every privilege available to any user on any object. That is, only
+ operations specified for the appropriate combination of object, role, group, and user
+ are allowed. All other operations are not allowed. If a group or role is defined
+ multiple times in the policy file, the last definition takes precedence.
+ </p>
+
+ <p>
+ To understand the notion of whitelisting, set up a minimal policy file that does not
+ provide any privileges for any object. When you connect to an Impala node where this
+ policy file is in effect, you get no results for <codeph>SHOW DATABASES</codeph>, and an
+ error when you issue any <codeph>SHOW TABLES</codeph>, <codeph>USE
+ <varname>database_name</varname></codeph>, <codeph>DESCRIBE
+ <varname>table_name</varname></codeph>, <codeph>SELECT</codeph>, and or other statements
+ that expect to access databases or tables, even if the corresponding databases and
+ tables exist.
+ </p>
+
+ <p>
+ The contents of the policy file are cached, to avoid a performance penalty for each
+ query. The policy file is re-checked by each <cmdname>impalad</cmdname> node every 5
+ minutes. When you make a non-time-sensitive change such as adding new privileges or new
+ users, you can let the change take effect automatically a few minutes later. If you
+ remove or reduce privileges, and want the change to take effect immediately, restart the
+ <cmdname>impalad</cmdname> daemon on all nodes, again specifying the
+ <codeph>-server_name</codeph> and <codeph>-authorization_policy_file</codeph> options so
+ that the rules from the updated policy file are applied.
+ </p>
+
</conbody>
+
<concept id="security_policy_file_details">
+
<title>Policy File Format</title>
+
<conbody>
- <p> The policy file uses the familiar <codeph>.ini</codeph> format,
- divided into the major sections <codeph>[groups]</codeph> and
- <codeph>[roles]</codeph>. </p>
- <p> There is also an optional <codeph>[databases]</codeph> section,
- which allows you to specify a specific policy file for a particular
- database, as explained in <xref href="#security_multiple_policy_files"
- />. </p>
- <p> Another optional section, <codeph>[users]</codeph>, allows you to
- override the OS-level mapping of users to groups; that is an advanced
- technique primarily for testing and debugging, and is beyond the scope
- of this document. </p>
- <p> In the <codeph>[groups]</codeph> section, you define various
- categories of users and select which roles are associated with each
- category. The group and usernames correspond to Linux groups and users
- on the server where the <cmdname>impalad</cmdname> daemon runs. </p>
- <p> The group and usernames in the <codeph>[groups]</codeph> section
- correspond to Hadoop groups and users on the server where the
- <cmdname>impalad</cmdname> daemon runs. When you access Impala
- through the <cmdname>impalad</cmdname> interpreter, for purposes of
- authorization, the user is the logged-in Linux user and the groups are
- the Linux groups that user is a member of. When you access Impala
- through the ODBC or JDBC interfaces, the user and password specified
- through the connection string are used as login credentials for the
- Linux server, and authorization is based on that username and the
- associated Linux group membership. </p>
- <p> In the <codeph>[roles]</codeph> section, you a set of roles. For
- each role, you specify precisely the set of privileges is available.
- That is, which objects users with that role can access, and what
- operations they can perform on those objects. This is the lowest-level
- category of security information; the other sections in the policy
- file map the privileges to higher-level divisions of groups and users.
- In the <codeph>[groups]</codeph> section, you specify which roles are
- associated with which groups. The group and usernames correspond to
- Linux groups and users on the server where the
- <cmdname>impalad</cmdname> daemon runs. The privileges are specified
- using patterns like:
- <codeblock>server=<varname>server_name</varname>->db=<varname>database_name</varname>->table=<varname>table_name</varname>->action=SELECT
+
+ <p>
+ The policy file uses the familiar <codeph>.ini</codeph> format, divided into the major
+ sections <codeph>[groups]</codeph> and <codeph>[roles]</codeph>.
+ </p>
+
+ <p>
+ There is also an optional <codeph>[databases]</codeph> section, which allows you to
+ specify a specific policy file for a particular database, as explained in
+ <xref href="#security_multiple_policy_files"
+ />.
+ </p>
+
+ <p>
+ Another optional section, <codeph>[users]</codeph>, allows you to override the
+ OS-level mapping of users to groups; that is an advanced technique primarily for
+ testing and debugging, and is beyond the scope of this document.
+ </p>
+
+ <p>
+ In the <codeph>[groups]</codeph> section, you define various categories of users and
+ select which roles are associated with each category. The group and usernames
+ correspond to Linux groups and users on the server where the
+ <cmdname>impalad</cmdname> daemon runs.
+ </p>
+
+ <p>
+ The group and usernames in the <codeph>[groups]</codeph> section correspond to Hadoop
+ groups and users on the server where the <cmdname>impalad</cmdname> daemon runs. When
+ you access Impala through the <cmdname>impalad</cmdname> interpreter, for purposes of
+ authorization, the user is the logged-in Linux user and the groups are the Linux
+ groups that user is a member of. When you access Impala through the ODBC or JDBC
+ interfaces, the user and password specified through the connection string are used as
+ login credentials for the Linux server, and authorization is based on that username
+ and the associated Linux group membership.
+ </p>
+
+ <p>
+ In the <codeph>[roles]</codeph> section, you a set of roles. For each role, you
+ specify precisely the set of privileges is available. That is, which objects users
+ with that role can access, and what operations they can perform on those objects. This
+ is the lowest-level category of security information; the other sections in the policy
+ file map the privileges to higher-level divisions of groups and users. In the
+ <codeph>[groups]</codeph> section, you specify which roles are associated with which
+ groups. The group and usernames correspond to Linux groups and users on the server
+ where the <cmdname>impalad</cmdname> daemon runs. The privileges are specified using
+ patterns like:
+<codeblock>server=<varname>server_name</varname>->db=<varname>database_name</varname>->table=<varname>table_name</varname>->action=SELECT
server=<varname>server_name</varname>->db=<varname>database_name</varname>->table=t<varname>able_name</varname>->action=CREATE
server=<varname>server_name</varname>->db=<varname>database_name</varname>->table=<varname>table_name</varname>->action=ALL
</codeblock>
- For the <varname>server_name</varname> value, substitute the same
- symbolic name you specify with the <cmdname>impalad</cmdname>
- <codeph>-server_name</codeph> option. You can use <codeph>*</codeph>
- wildcard characters at each level of the privilege specification to
- allow access to all such objects. For example:
- <codeblock>server=impala-host.example.com->db=default->table=t1->action=SELECT
+ For the <varname>server_name</varname> value, substitute the same symbolic name you
+ specify with the <cmdname>impalad</cmdname> <codeph>-server_name</codeph> option. You
+ can use <codeph>*</codeph> wildcard characters at each level of the privilege
+ specification to allow access to all such objects. For example:
+<codeblock>server=impala-host.example.com->db=default->table=t1->action=SELECT
server=impala-host.example.com->db=*->table=*->action=CREATE
server=impala-host.example.com->db=*->table=audit_log->action=SELECT
server=impala-host.example.com->db=default->table=t1->action=*
</codeblock>
</p>
+
</conbody>
+
</concept>
+
<concept id="security_multiple_policy_files">
+
<title>Using Multiple Policy Files for Different Databases</title>
+
<conbody>
- <p> For an Impala cluster with many databases being accessed by many
- users and applications, it might be cumbersome to update the security
- policy file for each privilege change or each new database, table, or
- view. You can allow security to be managed separately for individual
- databases, by setting up a separate policy file for each database: </p>
+
+ <p>
+ For an Impala cluster with many databases being accessed by many users and
+ applications, it might be cumbersome to update the security policy file for each
+ privilege change or each new database, table, or view. You can allow security to be
+ managed separately for individual databases, by setting up a separate policy file for
+ each database:
+ </p>
+
<ul>
- <li> Add the optional <codeph>[databases]</codeph> section to the main
- policy file. </li>
- <li> Add entries in the <codeph>[databases]</codeph> section for each
- database that has its own policy file. </li>
- <li> For each listed database, specify the HDFS path of the
- appropriate policy file. </li>
+ <li>
+ Add the optional <codeph>[databases]</codeph> section to the main policy file.
+ </li>
+
+ <li>
+ Add entries in the <codeph>[databases]</codeph> section for each database that has
+ its own policy file.
+ </li>
+
+ <li>
+ For each listed database, specify the HDFS path of the appropriate policy file.
+ </li>
</ul>
- <p> For example: </p>
- <codeblock>[databases]
+
+ <p>
+ For example:
+ </p>
+
+<codeblock>[databases]
# Defines the location of the per-DB policy files for the 'customers' and 'sales' databases.
customers = hdfs://ha-nn-uri/etc/access/customers.ini
sales = hdfs://ha-nn-uri/etc/access/sales.ini
</codeblock>
- <p> To enable URIs in per-DB policy files, the Java configuration option
- <codeph>sentry.allow.uri.db.policyfile</codeph> must be set to
- <codeph>true</codeph>. For example: </p>
- <codeblock>JAVA_TOOL_OPTIONS="-Dsentry.allow.uri.db.policyfile=true"
+
+ <p>
+ To enable URIs in per-DB policy files, the Java configuration option
+ <codeph>sentry.allow.uri.db.policyfile</codeph> must be set to <codeph>true</codeph>.
+ For example:
+ </p>
+
+<codeblock>JAVA_TOOL_OPTIONS="-Dsentry.allow.uri.db.policyfile=true"
</codeblock>
- <note type="important"> Enabling URIs in per-DB policy files introduces
- a security risk by allowing the owner of the db-level policy file to
- grant himself/herself load privileges to anything the
- <codeph>impala</codeph> user has read permissions for in HDFS
- (including data in other databases controlled by different db-level
- policy files). </note>
+
+ <note type="important">
+ Enabling URIs in per-DB policy files introduces a security risk by allowing the owner
+ of the db-level policy file to grant himself/herself load privileges to anything the
+ <codeph>impala</codeph> user has read permissions for in HDFS (including data in other
+ databases controlled by different db-level policy files).
+ </note>
+
</conbody>
+
</concept>
+
</concept>
+
<concept id="security_schema">
+
<title>Setting Up Schema Objects for a Secure Impala Deployment</title>
+
<conbody>
- <p> In your role definitions, you must specify privileges at the level of
- individual databases and tables, or all databases or all tables within a
- database. To simplify the structure of these rules, plan ahead of time
- how to name your schema objects so that data with different
- authorization requirements is divided into separate databases. </p>
- <p> If you are adding security on top of an existing Impala deployment,
- you can rename tables or even move them between databases using the
- <codeph>ALTER TABLE</codeph> statement. </p>
+
+ <p>
+ In your role definitions, you must specify privileges at the level of individual
+ databases and tables, or all databases or all tables within a database. To simplify the
+ structure of these rules, plan ahead of time how to name your schema objects so that
+ data with different authorization requirements is divided into separate databases.
+ </p>
+
+ <p>
+ If you are adding security on top of an existing Impala deployment, you can rename
+ tables or even move them between databases using the <codeph>ALTER TABLE</codeph>
+ statement.
+ </p>
+
</conbody>
+
</concept>
+
<concept id="sentry_debug">
+
<title><ph conref="../shared/impala_common.xml#common/title_sentry_debug"
/></title>
+
<conbody>
+
<p conref="../shared/impala_common.xml#common/sentry_debug"/>
+
</conbody>
+
</concept>
+
<concept id="sec_ex_default">
+
<title>The DEFAULT Database in a Secure Deployment</title>
+
<conbody>
- <p> Because of the extra emphasis on granular access controls in a secure
- deployment, you should move any important or sensitive information out
- of the <codeph>DEFAULT</codeph> database into a named database whose
- privileges are specified in the policy file. Sometimes you might need to
- give privileges on the <codeph>DEFAULT</codeph> database for
- administrative reasons; for example, as a place you can reliably specify
- with a <codeph>USE</codeph> statement when preparing to drop a database.
+
+ <p>
+ Because of the extra emphasis on granular access controls in a secure deployment, you
+ should move any important or sensitive information out of the <codeph>DEFAULT</codeph>
+ database into a named database whose privileges are specified in the policy file.
+ Sometimes you might need to give privileges on the <codeph>DEFAULT</codeph> database for
+ administrative reasons; for example, as a place you can reliably specify with a
+ <codeph>USE</codeph> statement when preparing to drop a database.
</p>
+
</conbody>
+
</concept>
+
</concept>
http://git-wip-us.apache.org/repos/asf/impala/blob/0acf1b3a/docs/topics/impala_grant.xml
----------------------------------------------------------------------
diff --git a/docs/topics/impala_grant.xml b/docs/topics/impala_grant.xml
index bdc71db..fe23b4b 100644
--- a/docs/topics/impala_grant.xml
+++ b/docs/topics/impala_grant.xml
@@ -21,7 +21,13 @@ under the License.
<concept rev="2.0.0" id="grant">
<title>GRANT Statement (<keyword keyref="impala20"/> or higher only)</title>
- <titlealts audience="PDF"><navtitle>GRANT</navtitle></titlealts>
+
+ <titlealts audience="PDF">
+
+ <navtitle>GRANT</navtitle>
+
+ </titlealts>
+
<prolog>
<metadata>
<data name="Category" value="Impala"/>
@@ -33,16 +39,15 @@ under the License.
<data name="Category" value="Administrators"/>
<data name="Category" value="Developers"/>
<data name="Category" value="Data Analysts"/>
- <!-- Consider whether to go deeper into categories like Security for the Sentry-related statements. -->
+<!-- Consider whether to go deeper into categories like Security for the Sentry-related statements. -->
</metadata>
</prolog>
<conbody>
<p rev="2.0.0">
- <indexterm audience="hidden">GRANT statement</indexterm> The
- <codeph>GRANT</codeph> statement grants a privilege on a specified object
- to a role or grants a role to a group.
+ The <codeph>GRANT</codeph> statement grants a privilege on a specified object to a role or
+ grants a role to a group.
</p>
<p conref="../shared/impala_common.xml#common/syntax_blurb"/>
@@ -54,7 +59,7 @@ GRANT <varname>privilege</varname> ON <varname>object_type</varname> <varname>ob
[WITH GRANT OPTION]
<ph id="privileges" rev="3.0">privilege ::= ALL | ALTER | CREATE | DROP | INSERT | REFRESH | SELECT | SELECT(<varname>column_name</varname>)</ph>
-<ph id="priv_objs" rev="3.0">object_type ::= TABLE | DATABASE | SERVER | URI</ph>
+<ph id="priv_objs" rev="3.0">object_type ::= SERVER | URI | DATABASE | TABLE</ph>
</codeblock>
<p>
@@ -66,40 +71,39 @@ GRANT <varname>privilege</varname> ON <varname>object_type</varname> <varname>ob
<p conref="../shared/impala_common.xml#common/privileges_blurb"/>
<p>
- Only administrative users (initially, a predefined set of users
- specified in the Sentry service configuration file) can use this
- statement.
+ Only administrative users (initially, a predefined set of users specified in the Sentry
+ service configuration file) can use this statement.
+ </p>
+
+ <p>
+ Only Sentry administrative users can grant roles to a group.
+ </p>
+
+ <p>
+ The <codeph>WITH GRANT OPTION</codeph> clause allows members of the specified role to
+ issue <codeph>GRANT</codeph> and <codeph>REVOKE</codeph> statements for those same
+ privileges. Hence, if a role has the <codeph>ALL</codeph> privilege on a database and the
+ <codeph>WITH GRANT OPTION</codeph> set, users granted that role can execute
+ <codeph>GRANT</codeph>/<codeph>REVOKE</codeph> statements only for that database or child
+ tables of the database. This means a user could revoke the privileges of the user that
+ provided them the <codeph>GRANT OPTION</codeph>.
</p>
- <p>Only Sentry administrative users can grant roles to a group. </p>
-
- <p> The <codeph>WITH GRANT OPTION</codeph> clause allows members of the
- specified role to issue <codeph>GRANT</codeph> and <codeph>REVOKE</codeph>
- statements for those same privileges. Hence, if a role has the
- <codeph>ALL</codeph> privilege on a database and the <codeph>WITH GRANT
- OPTION</codeph> set, users granted that role can execute
- <codeph>GRANT</codeph>/<codeph>REVOKE</codeph> statements only for that
- database or child tables of the database. This means a user could revoke
- the privileges of the user that provided them the <codeph>GRANT
- OPTION</codeph>. </p>
-
- <p> Impala does not currently support revoking only the <codeph>WITH GRANT
- OPTION</codeph> from a privilege previously granted to a role. To remove
- the <codeph>WITH GRANT OPTION</codeph>, revoke the privilege and grant it
- again without the <codeph>WITH GRANT OPTION</codeph> flag. </p>
<p rev="2.3.0 collevelauth">
- The ability to grant or revoke <codeph>SELECT</codeph> privilege on specific columns is available
- in <keyword keyref="impala23_full"/> and higher. See <xref keyref="sg_hive_sql"/> for details.
+ The ability to grant or revoke <codeph>SELECT</codeph> privilege on specific columns is
+ available in <keyword keyref="impala23_full"/> and higher. See
+ <xref keyref="sg_hive_sql"/> for details.
</p>
+
<p>
<b>Usage notes:</b>
</p>
<p>
- You can only grant the <codeph>ALL</codeph> privilege to the
- <codeph>URI</codeph> object. Finer-grained privileges mentioned below on
- a <codeph>URI</codeph> are not supported.
+ You can only grant the <codeph>ALL</codeph> privilege to the <codeph>URI</codeph> object.
+ Finer-grained privileges mentioned below on a <codeph>URI</codeph> are not supported.
</p>
+
<p conref="../shared/impala_common.xml#common/sentry_privileges_objects"/>
<p conref="../shared/impala_common.xml#common/compatibility_blurb"/>
@@ -107,20 +111,21 @@ GRANT <varname>privilege</varname> ON <varname>object_type</varname> <varname>ob
<p>
<ul>
<li>
- The Impala <codeph>GRANT</codeph> and <codeph>REVOKE</codeph> statements are available in
- <keyword keyref="impala20_full"/> and later.
+ The Impala <codeph>GRANT</codeph> and <codeph>REVOKE</codeph> statements are available
+ in <keyword keyref="impala20_full"/> and later.
</li>
<li>
- In <keyword keyref="impala14_full"/> and later, Impala can make use of any roles and privileges specified by the
- <codeph>GRANT</codeph> and <codeph>REVOKE</codeph> statements in Hive, when your system is configured to
- use the Sentry service instead of the file-based policy mechanism.
+ In <keyword keyref="impala14_full"/> and later, Impala can make use of any roles and
+ privileges specified by the <codeph>GRANT</codeph> and <codeph>REVOKE</codeph>
+ statements in Hive, when your system is configured to use the Sentry service instead
+ of the file-based policy mechanism.
</li>
<li>
- The Impala <codeph>GRANT</codeph> and <codeph>REVOKE</codeph> statements for privileges do not require
- the <codeph>ROLE</codeph> keyword to be repeated before each role name, unlike the equivalent Hive
- statements.
+ The Impala <codeph>GRANT</codeph> and <codeph>REVOKE</codeph> statements for
+ privileges do not require the <codeph>ROLE</codeph> keyword to be repeated before each
+ role name, unlike the equivalent Hive statements.
</li>
<li conref="../shared/impala_common.xml#common/grant_revoke_single"/>
@@ -132,14 +137,18 @@ GRANT <varname>privilege</varname> ON <varname>object_type</varname> <varname>ob
<p conref="../shared/impala_common.xml#common/permissions_blurb_no"/>
<p conref="../shared/impala_common.xml#common/kudu_blurb"/>
+
<p conref="../shared/impala_common.xml#common/kudu_sentry_limitations"/>
<p conref="../shared/impala_common.xml#common/related_info"/>
<p>
- <xref href="impala_authorization.xml#authorization"/>, <xref href="impala_revoke.xml#revoke"/>,
- <xref href="impala_create_role.xml#create_role"/>, <xref href="impala_drop_role.xml#drop_role"/>,
- <xref href="impala_show.xml#show"/>
+ <xref href="impala_authorization.xml#authorization"/>,
+ <xref href="impala_revoke.xml#revoke"/>,
+ <xref href="impala_create_role.xml#create_role"/>,
+ <xref href="impala_drop_role.xml#drop_role"/>, <xref href="impala_show.xml#show"/>
</p>
+
</conbody>
+
</concept>
http://git-wip-us.apache.org/repos/asf/impala/blob/0acf1b3a/docs/topics/impala_revoke.xml
----------------------------------------------------------------------
diff --git a/docs/topics/impala_revoke.xml b/docs/topics/impala_revoke.xml
index 4c997f8..25992b1 100644
--- a/docs/topics/impala_revoke.xml
+++ b/docs/topics/impala_revoke.xml
@@ -21,7 +21,13 @@ under the License.
<concept rev="2.0.0" id="revoke">
<title>REVOKE Statement (<keyword keyref="impala20"/> or higher only)</title>
- <titlealts audience="PDF"><navtitle>REVOKE</navtitle></titlealts>
+
+ <titlealts audience="PDF">
+
+ <navtitle>REVOKE</navtitle>
+
+ </titlealts>
+
<prolog>
<metadata>
<data name="Category" value="Impala"/>
@@ -33,44 +39,58 @@ under the License.
<data name="Category" value="Administrators"/>
<data name="Category" value="Developers"/>
<data name="Category" value="Data Analysts"/>
- <!-- Consider whether to go deeper into categories like Security for the Sentry-related statements. -->
+<!-- Consider whether to go deeper into categories like Security for the Sentry-related statements. -->
</metadata>
</prolog>
<conbody>
<p rev="2.0.0">
- The <codeph>REVOKE</codeph> statement revokes roles or
- privileges on a specified object from groups.
+ The <codeph>REVOKE</codeph> statement revokes roles or privileges on a specified object
+ from groups.
</p>
<p conref="../shared/impala_common.xml#common/syntax_blurb"/>
<codeblock rev="2.3.0 collevelauth">REVOKE ROLE <varname>role_name</varname> FROM GROUP <varname>group_name</varname>
-REVOKE <varname>privilege</varname> ON <varname>object_type</varname> <varname>object_name</varname>
+REVOKE [GRANT OPTION FOR] <varname>privilege</varname> ON <varname>object_type</varname> <varname>object_name</varname>
FROM [ROLE] <varname>role_name</varname>
<ph rev="3.0">
privilege ::= ALL | ALTER | CREATE | DROP | INSERT | REFRESH | SELECT | SELECT(<varname>column_name</varname>)
</ph>
-<ph rev="3.0">
- object_type ::= TABLE | DATABASE | SERVER | URI
-</ph>
-</codeblock>
+<ph id="priv_objs" rev="3.0">object_type ::= SERVER | URI | DATABASE | TABLE</ph></codeblock>
<p>
- See <keyword keyref="grant"/> for the required privileges and the scope
- for SQL operations.
+ <b>Usage notes:</b>
</p>
<p>
- The <codeph>ALL</codeph> privilege is a distinct privilege and not a
- union of all other privileges. Revoking <codeph>SELECT</codeph>,
- <codeph>INSERT</codeph>, etc. from a role that only has the
- <codeph>ALL</codeph> privilege has no effect. To reduce the privileges
- of that role you must <codeph>REVOKE ALL</codeph> and
- <codeph>GRANT</codeph> the desired privileges.
+ See <keyword keyref="grant"/> for the required privileges and the scope for SQL
+ operations.
+ </p>
+
+ <p>
+ The <codeph>ALL</codeph> privilege is a distinct privilege and not a union of all other
+ privileges. Revoking <codeph>SELECT</codeph>, <codeph>INSERT</codeph>, etc. from a role
+ that only has the <codeph>ALL</codeph> privilege has no effect. To reduce the privileges
+ of that role you must <codeph>REVOKE ALL</codeph> and <codeph>GRANT</codeph> the desired
+ privileges.
+ </p>
+
+ <p>
+ You cannot revoke a privilege granted with the <codeph>WITH GRANT OPTION</codeph>. If a
+ privilege is granted with the <codeph>WITH GRANT OPTION</codeph>, first revoke the grant
+ option, and then revoke the privilege.
+ </p>
+
+ <p>
+ For example:
+<codeblock>GRANT ALL ON SERVER TO ROLE foo_role;
+...
+REVOKE GRANT OPTION FOR ALL ON SERVER FROM ROLE foo_role;
+REVOKE ALL ON SERVER FROM ROLE foo_role;</codeblock>
</p>
<p>
@@ -78,38 +98,42 @@ REVOKE <varname>privilege</varname> ON <varname>object_type</varname> <varname>o
</p>
<p rev="2.3.0 collevelauth">
- The ability to grant or revoke <codeph>SELECT</codeph> privilege on specific columns is available
- in <keyword keyref="impala23_full"/> and higher. See
+ The ability to grant or revoke <codeph>SELECT</codeph> privilege on specific columns is
+ available in <keyword keyref="impala23_full"/> and higher. See
<xref keyref="sg_hive_sql"/> for details.
</p>
<p conref="../shared/impala_common.xml#common/privileges_blurb"/>
<p>
- Only administrative users (those with <codeph>ALL</codeph> privileges on the server, defined in the Sentry
- policy file) can use this statement.
+ Only administrative users (those with <codeph>ALL</codeph> privileges on the server,
+ defined in the Sentry policy file) can use this statement.
+ </p>
+
+ <p>
+ Only Sentry administrative users can revoke the role from a group.
</p>
- <p>Only Sentry administrative users can revoke the role from a group.</p>
<p conref="../shared/impala_common.xml#common/compatibility_blurb"/>
<p>
<ul>
<li>
- The <codeph>REVOKE</codeph> statements are available in <keyword
+ The <codeph>REVOKE</codeph> statements are available in
+ <keyword
keyref="impala20_full"/> and higher.
</li>
<li>
- In <keyword keyref="impala14_full"/> and higher, Impala makes use of any roles and privileges specified by the
- <codeph>GRANT</codeph> and <codeph>REVOKE</codeph> statements in Hive, when your system is configured to
- use the Sentry service instead of the file-based policy mechanism.
+ In <keyword keyref="impala14_full"/> and higher, Impala makes use of any roles and
+ privileges specified by the <codeph>GRANT</codeph> and <codeph>REVOKE</codeph>
+ statements in Hive, when your system is configured to use the Sentry service instead
+ of the file-based policy mechanism.
</li>
<li>
- The Impala <codeph>REVOKE</codeph> statements do not require the
- <codeph>ROLE</codeph> keyword to be repeated before each role name,
- unlike the equivalent Hive statements.
+ The Impala <codeph>REVOKE</codeph> statements do not require the <codeph>ROLE</codeph>
+ keyword to be repeated before each role name, unlike the equivalent Hive statements.
</li>
<li conref="../shared/impala_common.xml#common/grant_revoke_single"/>
@@ -121,14 +145,17 @@ REVOKE <varname>privilege</varname> ON <varname>object_type</varname> <varname>o
<p conref="../shared/impala_common.xml#common/permissions_blurb_no"/>
<p rev="2.8.0" conref="../shared/impala_common.xml#common/kudu_blurb"/>
+
<p conref="../shared/impala_common.xml#common/kudu_sentry_limitations"/>
<p conref="../shared/impala_common.xml#common/related_info"/>
<p>
- <xref href="impala_authorization.xml#authorization"/>, <xref href="impala_grant.xml#grant"/>
- <xref href="impala_create_role.xml#create_role"/>, <xref href="impala_drop_role.xml#drop_role"/>,
- <xref href="impala_show.xml#show"/>
+ <xref href="impala_authorization.xml#authorization"/>,
+ <xref href="impala_grant.xml#grant"/> <xref href="impala_create_role.xml#create_role"/>,
+ <xref href="impala_drop_role.xml#drop_role"/>, <xref href="impala_show.xml#show"/>
</p>
+
</conbody>
+
</concept>