Categories:
User & Security DDL (Access Control)

REVOKE <privileges> … FROM ROLE

Removes one or more privileges on a securable object from a role. The privileges that can be revoked are object-specific and are grouped into the following categories:

  • Global privileges.
  • Privileges for account objects (resource monitors, virtual warehouses, and databases).
  • Privileges for schemas.
  • Privileges for schema objects (tables, views, stages, file formats, UDFs, and sequences).

For more details about roles and securable objects, see Access Control in Snowflake.

See also:

GRANT <privileges> … TO ROLE , GRANT OWNERSHIP

REVOKE <privilege> … FROM SHARE

Syntax

REVOKE [ GRANT OPTION FOR ]
    {
       { globalPrivileges | ALL [ PRIVILEGES ] }        ON ACCOUNT
     | { accountObjectPrivileges | ALL [ PRIVILEGES ] } ON { RESOURCE MONITOR | WAREHOUSE | DATABASE } <object_name>
     | { schemaPrivileges | ALL [ PRIVILEGES ] }        ON { SCHEMA <schema_name> | ALL SCHEMAS IN DATABASE <db_name> }
     | { schemaObjectPrivileges | ALL [ PRIVILEGES ] }  ON { <object_type> <object_name> | ALL <object_type>S IN SCHEMA <schema_name> }
     | { schemaObjectPrivileges | ALL [ PRIVILEGES ] }  ON FUTURE <object_type>S IN SCHEMA <schema_name>
    }
  FROM [ ROLE ] <role_name> [ RESTRICT | CASCADE ]

Where:

globalPrivileges
globalPrivileges ::=
  { { CREATE { ROLE | USER | WAREHOUSE | DATABASE } } | MANAGE GRANTS | MONITOR USAGE } [ , ... ]
accountObjectPrivileges
accountObjectPrivileges ::=
-- For RESOURCE MONITOR
  { MODIFY | MONITOR } [ , ... ]
-- For WAREHOUSE
  { MODIFY | MONITOR | USAGE | OPERATE } [ , ... ]
-- For DATABASE
  { MODIFY | MONITOR | USAGE | CREATE SCHEMA | IMPORTED PRIVILEGES } [ , ... ]
schemaPrivileges
schemaPrivileges ::=
  { MODIFY | MONITOR | USAGE | CREATE { TABLE | VIEW | FILE FORMAT | STAGE | PIPE | FUNCTION | PROCEDURE | SEQUENCE } } [ , ... ]
schemaObjectPrivileges
schemaObjectPrivileges ::=
-- For TABLE
  { SELECT | INSERT | UPDATE | DELETE | TRUNCATE | REFERENCES } [ , ... ]
-- For VIEW
    SELECT
-- For internal STAGE
    READ [ , WRITE ]
-- For external STAGE
    USAGE
-- For FILE FORMAT, UDF, SEQUENCE
    USAGE

For more details about the privileges supported for each object type, see Access Control Privileges.

Required Parameters

object_name
Specifies the identifier for the object on which the privileges are revoked.
object_type

Specifies the type of object (for schema objects):

TABLE | VIEW | STAGE | FILE FORMAT | FUNCTION | PROCEDURE | SEQUENCE
role_name
Specifies the identifier for the recipient role (i.e. the role from which the privileges are revoked).

Optional Parameters

GRANT OPTION FOR

If specified, removes the ability for the recipient role to grant the privileges to another role.

Default: No value

ON FUTURE
If specified, only removes privileges granted on new (i.e. future) schema objects of a specified type (e.g. tables or views) rather than existing objects. Note that any privileges granted on existing objects are retained.
RESTRICT | CASCADE

If specified, determines whether the revoke operation succeeds or fails for the privileges, based on the whether the privileges had been re-granted to another role.

  • RESTRICT: If the privilege being revoked has been re-granted to another role, the REVOKE command fails.
  • CASCADE: If the privilege being revoked has been re-granted, the REVOKE command recursively revokes these dependent grants. If the same privilege on an object has been granted to the target role by a different grantor (parallel grant), that grant is not affected and the target role retains the privilege.

Default: RESTRICT

Usage Notes

  • Multiple privileges can be specified for the same object type in a single GRANT statement (with each privilege separated by commas), or the special ALL [ PRIVILEGES ] keyword can be used to grant all applicable privileges to the specified object type. Note, however, that only privileges held and grantable by the role executing the GRANT command are actually granted to the target role. A warning message is returned for any privileges that could not be granted.

  • Privileges granted to a particular role are automatically inherited by any other roles to which the role is granted, as well as any other higher-level roles within the role hierarchy. For more details, see Access Control in Snowflake.

  • For databases, the IMPORTED PRIVILEGES privilege only applies to shared databases (i.e. databases created from a share). For more details, see Data Consumers.

  • For schemas and objects in schemas, an option is provided to grant privileges on all objects of the same type within the container (i.e. database or schema). This is a convenience option; internally, the command is expanded into a series of individual GRANT commands on each object. Only objects that currently exist within the container are affected.

    However, note that, in the Snowflake model, bulk granting of privileges is not a recommended practice. Instead, we recommend creating a shared role and using the role to create objects that are automatically accessible to all users who have been granted the role.

  • For stages:

    • USAGE only applies to external stages.
    • READ | WRITE only applies to internal stages. In addition, to grant the WRITE privilege on an internal stage, the READ privilege must first be granted on the stage.

    For more details about external and internal stages, see CREATE STAGE.

  • When granting privileges on an individual UDF, you must specify the data types for the arguments, if any, for the UDF in the form of udf_name ( [ arg_data_type , ... ] ). This is required because Snowflake uses argument data types to resolve UDFs that have the same name within a schema. For an example, see Examples (in this topic). For more details, see Overview of UDFs.

  • When granting privileges on an individual stored procedure, you must specify the data types for the arguments, if any, for the procedure in the form of procedure_name ( [ arg_data_type , ... ] ). This is required because Snowflake uses argument data types to resolve stored procedures that have the same name within a schema.

  • Security administrators who have been granted the MANAGE GRANTS privilege can view and modify any grant assignment in the system.

Examples

Revoke the necessary privileges to operate (i.e. suspend or resume) the report_wh warehouse from the analyst role:

REVOKE OPERATE ON WAREHOUSE report_wh FROM ROLE analyst;

Same as previous example, but also allow the analyst role to grant the privilege to other roles:

REVOKE GRANT OPTION FOR OPERATE ON WAREHOUSE report_wh FROM ROLE analyst;

Revoke the SELECT privilege on all existing tables in the mydb.myschema schema from the analyst role:

REVOKE SELECT ON ALL TABLES IN SCHEMA mydb.myschema from ROLE analyst;

Revoke all privileges on two UDFs (with the same name in the current schema) from the analyst role:

REVOKE ALL PRIVILEGES ON FUNCTION add5(number) FROM ROLE analyst;

REVOKE ALL PRIVILEGES ON FUNCTION add5(string) FROM ROLE analyst;

Note that the UDFs have different arguments, which is how Snowflake uniquely identifies UDFs with the same name. For more details about UDF naming, see Overview of UDFs.

Revoke all privileges on two stored procedures (with the same name in the current schema) from the analyst role:

REVOKE ALL PRIVILEGES ON PROCEDURE clean_schema(string) FROM ROLE analyst;

REVOKE ALL PRIVILEGES ON procedure clean_schema(string, string) FROM ROLE analyst;

Note that the two stored procedures have different arguments, which is how Snowflake uniquely identifies procedures with the same name.

Revoke the SELECT and INSERT privileges granted on all future tables created in the mydb.myschema schema from the role1 role:

REVOKE SELECT,INSERT ON FUTURE TABLES IN SCHEMA mydb.myschema
FROM ROLE role1;