Galaxy privileges basics #

A privilege granted to a role conveys the right to perform specific operations.

The grantor of a privilege is not recorded as part of a grant, but is only stored in the audit log.

Entity privileges grant rights to a single entity or collection of entities of the same type. For example, when granting the right to SELECT rows from a specific table, table is the entity.

Account privileges are not associated with a particular data entity, but apply to the Starburst Galaxy account as a whole. Account-level privileges include rights to create new data entities, such as clusters, catalogs, and users, and includes the rights to manage security for all entities.

Learn more about specific account and cluster privileges.

Learn about data privileges such as catalog, schema, table or view, and column-level.

Grant a privilege #

One role can be used to grant a privilege for a specific entity to any other role under the following circumstances:

• Role includes the grant WITH ADMIN OPTION
• Role is the owner of the entity.
• Role has the Manage security role.

Deny a privilege #

The effect of a privilege grant on an entity to a role can be reversed by granting a deny privilege to that role. This is most useful for table privileges, but any inherited privilege on any entity can be denied. Learn more details in wildcard privileges.

A deny privilege grant can create an exception to a wildcard privilege grant, preventing the access that the privilege grant previously allowed.

Deny privilege grants always override grants that allow access, including any inherited from roles and wildcards. Deny privilege grants should therefore be rarely used, and are typically used only to override a wildcard grant.

Deny privileges are most useful for schemas and tables, to create exceptions to wildcard privilege grants. However, any privilege grant to a role or inherited from a child role on any entity can be reversed with a deny privilege grant to the role. For example, “upper_role” might inherit privilege Create user from “lower_role”. That privilege can be reversed by granting a deny privilege for Create user to “upper_role”.

You can create deny privileges in the UI using the privileges dialogs. The following examples of using the SQL statement DENY correspond to the examples from the wildcard privileges section:

You can deny table privileges to a role with SQL:

DENY SELECT ON "prod_data.monthly_sales"."*" TO read_only_users

You can deny a CREATE_TABLE privilege on the schema monthly_sales this way:

DENY CREATE ON SCHEMA prod_data.monthly_sales

SQL does not provide a mechanism to grant or deny privileges on clusters, users, or catalogs.

SQL privileges #

You can manage adding and removing privileges from some but not all entities using SQL commands, as discussed in SQL privileges.