GRANT PERMISSION

Synopsis

The GRANT PERMISSION statement is used to grant a permission (or all the available permissions) to a role.

When a database object is created (keyspace, table, or role), an automatic and explicit grant of all the permissions relevant to the object are granted to the role creating it.

This statement is enabled by setting the YB-TServer configuration option use_cassandra_authentication to true.

Syntax

Diagram

grant_permission

GRANT PERMISSION - 图1

all_permissions

GRANT PERMISSION - 图2

permission

GRANT PERMISSION - 图3

resource

GRANT PERMISSION - 图4

Grammar

  1. grant_permission := GRANT all_permission | permission ON resource TO role_name;
  2. all_permissions := ALL [ PERMISSIONS ]
  3. permission :=  ( CREATE | ALTER | DROP | SELECT | MODIFY | AUTHORIZE | DESCRIBE | EXECUTE ) [ PERMISSION ]
  4. resource := ALL ( KEYSPACES | ROLES ) | KEYSPACE keyspace_name | [ TABLE ] table_name | ROLE role_name;

Where

  • keyspace_name, table_name, and role_name are text identifiers (table_name may be qualified with a keyspace name).

Semantics

  • Permission AUTHORIZE on ALL ROLES or on the role being used in the statement is necessary. Otherwise, an unauthorized error will be returned.

Permissions

This section describes the permissions (represented by ALTER, AUTHORIZE, CREATE, DESCRIBE, DROP, MODIFY, and SELECT) that are necessary to execute operations on the database objects. A permission can be granted on a specific object (represented by resources KEYSPACE, TABLE, and ROLE) or on a whole group of objects (represented by resources ALL KEYSPACES, and ALL ROLES). Some permissions are granted implicitly, which means that you will never see them listed when you query system_auth.role_permissions table. Implicitly granted permissions follow these rules:

  • Any permission granted on ALL KEYSPACES is implicitly granted on every keyspace and table in the database.
  • Any permission granted on a specific KEYSPACE is implicitly granted to any table in that keyspace.
  • Any permission granted on ALL ROLES is implicitly granted on every role.

Permissions needed to execute specific operations on a database object

OperationPermissionResource
ALTER KEYSPACEALTERALL KEYSPACES, or KEYSPACE
ALTER ROLEALTERALL ROLES, or ROLE
ALTER TABLEALTERALL KEYSPACES, KEYSPACE, or TABLE
CREATE KEYSPACECREATEALL KEYSPACES
CREATE ROLECREATEALL ROLES
CREATE TABLECREATEALL KEYSPACES, KEYSPACE
DROP KEYSPACEDROPALL KEYSPACES, or KEYSPACE
DROP ROLEDROPALL ROLES, or ROLE
DROP TABLEDROPALL KEYSPACES, KEYSPACE, or TABLE
GRANT PERMISSION or REVOKE PERMISSION on ALL KEYSPACESAUTHORIZEALL KEYSPACES
GRANT PERMISSION or REVOKE PERMISSION on ALL ROLESAUTHORIZEALL ROLES
GRANT PERMISSION or REVOKE PERMISSION on a keyspaceAUTHORIZEALL KEYSPACES, or KEYSPACE
GRANT PERMISSION or REVOKE PERMISSION on a roleAUTHORIZEALL ROLES, or ROLE
GRANT PERMISSION or REVOKE PERMISSION on a tableAUTHORIZEALL KEYSPACES, KEYSPACE, or TABLE
GRANT ROLE or REVOKE ROLEAUTHORIZEALL ROLES, or ROLE
INSERT, UPDATE, DELETE, or TRUNCATEMODIFYALL KEYSPACES, KEYSPACE, or TABLE
LIST ROLES (not yet implemented)DESCRIBEALL ROLES
SELECTSELECTALL KEYSPACES, KEYSPACE, or TABLE

Examples

Grant MODIFY permission on a table so role qa can insert rows into a table.

  1. cqlsh:example> GRANT MODIFY ON TABLE performance_tests.metrics TO qa;

Grant SELECT permission on a table so role qa can read the table.

  1. cqlsh:example> GRANT SELECT ON performance_tests.metrics TO qa;

Grant CREATE permission on ALL KEYSPACES so role tests can create new keyspaces.

  1. cqlsh:example> GRANT CREATE ON ALL KEYSPACES TO tests;

See also