Roles and Privileges
HEAVY.AI supports data security using a set of database object access privileges granted to users or roles.
Users and Privileges
When you create a database, the admin superuser is created by default. The admin superuser is granted all privileges on all database objects. Superusers can create new users that, by default, have no database object privileges.
Superusers can grant users selective access privileges on multiple database objects using two mechanisms: role-based privileges and user-based privileges.
Role-based Privileges
- Grant roles access privileges on database objects.
- Grant roles to users.
- Grant roles to other roles.
User-based Privileges
When a user has privilege requirements that differ from role privileges, you can grant privileges directly to the user. These mechanisms provide data security for many users and classes of users to access the database.
You have the following options for granting privileges:
- Each object privilege can be granted to one or many roles, or to one or many users.
- A role and/or user can be granted privileges on one or many objects.
- A role can be granted to one or many users or other roles.
- A user can be granted one or many roles.
This supports the following many-to-many relationships:
- Objects and roles
- Objects and users
- Roles and users
These relationships provide flexibility and convenience when granting/revoking privileges to and from users.
Granting object privileges to roles and users, and granting roles to users, has a cumulative effect. The result of several grant commands is a combination of all individual grant commands. This applies to all database object types and to privileges inherited by objects. For example, object privileges granted to the object of database type are propagated to all table-type objects of that database object.
Who Can Grant Object Privileges?
Only a superuser or an object owner can grant privileges for on object.
- A superuser has all privileges on all database objects.
- A non-superuser user has only those privileges on a database object that are granted by a superuser.
- A non-superuser user has
ALLprivileges on a table created by that user.
Roles and Privileges Persistence
- Roles can be created and dropped at any time.
- Object privileges and roles can be granted or revoked at any time, and the action takes effect immediately.
- Privilege state is persistent and restored if the HEAVY.AI session is interrupted.
Database Object Privileges
There are five database object types, each with its own privileges.
Database
Table
View
Dashboard
Server
ACCESS - Connect to the database. The ACCESS privilege is a prerequisite for all other privileges at the database level. Without the ACCESS privilege, a user or role cannot perform tasks on any other database objects.
ALL - Allow all privileges on this database except issuing grants and dropping the database.
SELECT, INSERT, TRUNCATE, UPDATE, DELETE - Allow these operations on any table in the database.
ALTER SERVER - Alter servers in the current database.
CREATE SERVER - Create servers in the current database.
CREATE TABLE - Create a table in the current database. (Also CREATE.)
CREATE VIEW - Create a view for the current database.
CREATE DASHBOARD - Create a dashboard for the current database.
DELETE DASHBOARD - Delete a dashboard for this database.
DROP SERVER - Drop servers from the current database.
DROP - Drop a table from the database.
DROP VIEW - Drop a view for this database.
EDIT DASHBOARD - Edit a dashboard for this database.
SELECT VIEW - Select a view for this database.
SERVER USAGE - Use servers (through foreign tables) in the current database.
VIEW DASHBOARD - View a dashboard for this database.
VIEW SQL EDITOR - Access the SQL Editor in Immerse for this database.
Users with SELECT privilege on views do not require SELECT privilege on underlying tables referenced by the view to retrieve the data queried by the view. View queries work without error whether or not users have direct access to referenced tables. This also applies to views that query tables in other databases.
To create views, users must have SELECT privilege on queried tables in addition to the CREATE VIEW privilege.
Privileges granted on a database-type object are inherited by all tables of that database.
Privilege Commands
Example
The following example shows a valid sequence for granting access privileges to non-superuser user1 by granting a role to user1 and by directly granting a privilege. This example presumes that table1 and user1 already exist, and that user1 has ACCESS privileges on the database where table1 exists.
-
Create the
r_selectrole. -
Grant the SELECT privilege on
table1to ther_selectrole. Any user granted ther_selectrole gains the SELECT privilege. -
Grant the
r_selectrole touser1, givinguser1the SELECT privilege ontable1. -
Directly grant
user1the INSERT privilege ontable1.
See Example Roles and Privileges Session for a more complete example.
CREATE ROLE
Create a role. Roles are granted to users for role-based database object access.
This clause requires superuser privilege and <roleName> must not exist.
Synopsis
Parameters
<roleName>
Name of the role to create.
Example
Create a payroll department role called payrollDept.
See Also
DROP ROLE
Remove a role.
This clause requires superuser privilege and <roleName> must exist.
Synopsis
Parameters
<roleName>
Name of the role to drop.
Example
Remove the payrollDept role.
See Also
GRANT
Grant role privileges to users and to other roles.
The ACCESS privilege is a prerequisite for all other privileges at the database level. Without the ACCESS privilege, a user or role cannot perform tasks on any other database objects.
This clause requires superuser privilege. The specified <roleNames> and <userNames> must exist.
Synopsis
Parameters
<roleNames>
Names of roles to grant to users and other roles. Use commas to separate multiple role names.
<userNames>
Names of users. Use commas to separate multiple user names.
Examples
Assign payrollDept role privileges to user dennis.
Grant payrollDept and accountsPayableDept role privileges to users dennis and mike and role hrDept.
See Also
REVOKE
Remove role privilege from users or from other roles. This removes database object access privileges granted with the role.
This clause requires superuser privilege. The specified <roleNames> and <userNames> must exist.
Synopsis
Parameters
<roleNames>
Names of roles to remove from users and other roles. Use commas to separate multiple role names.
<userName>
Names of the users. Use commas to separate multiple user names.
Example
Remove payrollDept role privileges from user dennis.
Revoke payrollDept and accountsPayableDept role privileges from users dennis and fred and role hrDept.
See Also
GRANT ON TABLE
Define the privilege(s) a role or user has on the specified table. You can specify any combination of the INSERT, SELECT, DELETE, UPDATE, DROP, or TRUNCATE privilege or specify all privileges.
The ACCESS privilege is a prerequisite for all other privileges at the database level. Without the ACCESS privilege, a user or role cannot perform tasks on any other database objects.
This clause requires superuser privilege, or <tableName> must have been created by the user invoking this command. The specified <tableName> and users or roles defined in <entityList> must exist.
Synopsis
Parameters
<privilegeList>
<tableName>
Name of the database table.
<entityList>
Name of entity or entities to be granted the privilege(s).
Examples
Permit all privileges on the employees table for the payrollDept role.
Permit SELECT-only privilege on the employees table for user chris.
Permit INSERT-only privilege on the employees table for the hrdept and accountsPayableDept roles.
Permit INSERT, SELECT, and TRUNCATE privileges on the employees table for the role hrDept and for users dennis and mike.
See Also
REVOKE ON TABLE
Remove the privilege(s) a role or user has on the specified table. You can remove any combination of the INSERT, SELECT, DELETE, UPDATE, or TRUNCATE privileges, or remove all privileges.
This clause requires superuser privilege or <tableName> must have been created by the user invoking this command. The specified <tableName> and users or roles in <entityList> must exist.
Synopsis
Parameters
<privilegeList>
<tableName>
Name of the database table.
<entityList>
Name of entities to be denied the privilege(s).
Example
Prohibit SELECT and INSERT operations on the employees table for the nonemployee role.
Prohibit SELECT operations on the directors table for the employee role.
Prohibit INSERT operations on the directors table for role employee and user laura.
Prohibit INSERT, SELECT, and TRUNCATE privileges on the employees table for the role nonemployee and for users dennis and mike.
See Also
GRANT ON VIEW
Define the privileges a role or user has on the specified view. You can specify any combination of the SELECT, INSERT, or DROP privileges, or specify all privileges.
This clause requires superuser privileges, or <viewName> must have been created by the user invoking this command. The specified <viewName> and users or roles in <entityList> must exist.
Synopsis
Parameters
<privilegeList>
<viewName>
Name of the database view.
<entityList>
Name of entities to be granted the privileges.
Examples
Permit SELECT, INSERT, and DROP privileges on the employees view for the payrollDept role.
Permit SELECT-only privilege on the employees view for the employee role and user venkat.
Permit INSERT and DROP privileges on the employees view for the hrDept and acctPayableDept roles and users simon and dmitri.
See Also
REVOKE ON VIEW
Remove the privileges a role or user has on the specified view. You can remove any combination of the INSERT, DROP, or SELECT privileges, or remove all privileges.
This clause requires superuser privilege, or <viewName> must have been created by the user invoking this command. The specified <viewName> and users or roles in <entityList> must exist.
Synopsis
Parameters
<privilegeList>
<viewName>
Name of the database view.
<entityList>
Name of entity to be denied the privilege(s).
Example
Prohibit SELECT, DROP, and INSERT operations on the employees view for the nonemployee role.
Prohibit SELECT operations on the directors view for the employee role.
Prohibit INSERT and DROP operations on the directors view for the employee and manager role and for users ashish and lindsey.
See Also
GRANT ON DATABASE
Define the valid privileges a role or user has on the specified database. You can specify any combination of privileges, or specify all privileges.
The ACCESS privilege is a prerequisite for all other privileges at the database level. Without the ACCESS privilege, a user or role cannot perform tasks on any other database objects.
This clause requires superuser privileges.
Synopsis
Parameters
<privilegeList>
<dbName>
Name of the database, which must exist, created by CREATE DATABASE.
<entityList>
Name of the entity to be granted the privilege.
Examples
Permit all operations on the companydb database for the payrollDept role and user david.
Permit SELECT-only operations on the companydb database for the employee role.
Permit INSERT, UPDATE, and DROP operations on the companydb database for the hrdept and manager role and for users irene and stephen.
See Also
REVOKE ON DATABASE
Remove the operations a role or user can perform on the specified database. You can specify privileges individually or specify all privileges.
This clause requires superuser privilege or the user must own the database object. The specified <dbName> and roles or users in <entityList> must exist.
Synopsis
Parameters
<privilegeList>
<dbName>
Name of the database.
<entityList>
Example
Prohibit all operations on the employees database for the nonemployee role.
Prohibit SELECT operations on the directors database for the employee role and for user monica.
Prohibit INSERT, DROP, CREATE, and DELETE operations on the directors database for employee role and for users max and alex.
See Also
GRANT ON SERVER
Define the valid privileges a role or user has for working with servers. You can specify any combination of privileges or specify all privileges.
This clause requires superuser privileges, or <serverName> must have been created by the user invoking the command.
Synopsis
Parameters
<privilegeList>
<serverName>
Name of the server, which must exist on the current database, created by CREATE SERVER ON DATABASE.
<entityList>
Examples
Grant DROP privilege on server parquet_s3_server to user fred:
Grant ALTER privilege on server parquet_s3_server to role payrollDept:
Grant USAGE and ALTER privileges on server parquet_s3_server to role payrollDept and user jamie:
See Also
REVOKE ON SERVER
Remove privileges a role or user has for working with servers. You can specify any combination of privileges or specify all privileges.
This clause requires superuser privileges, or <serverName> must have been created by the user invoking the command.
Synopsis
Parameters
<privilegeList>
<serverName>
Name of the server, which must exist on the current database, created by CREATE SERVER ON DATABASE.
<entityList>
Examples
Revoke DROP privilege on server parquet_s3_server for user inga:
Grant ALTER privilege on server parquet_s3_server for role payrollDept:
Grant USAGE and ALTER privileges on server parquet_s3_server for role payrollDept and user marvin:
See Also
GRANT ON DASHBOARD
Define the valid privileges a role or user has for working with dashboards. You can specify any combination of privileges or specify all privileges.
This clause requires superuser privileges.
Synopsis
Parameters
<privilegeList>
<dashboardId>
ID of the dashboard, which must exist, created by CREATE DASHBOARD. To show a list of all dashboards and IDs in heavysql, run the \dash command when logged in as superuser.
<entityList>
Examples
Permit all privileges on the dashboard ID 740 for the payrollDept role.
Permit VIEW-only privilege on dashboard 730 for the hrDept role and user dennis.
Permit EDIT and DELETE privileges on dashboard 740 for the hrDept and accountsPayableDept roles and for user pavan.
See Also
REVOKE ON DASHBOARD
Remove privileges a role or user has for working with dashboards. You can specify any combination of privileges, or all privileges.
This clause requires superuser privileges.
Synopsis
Parameters
<privilegeList>
<dashboardId>
ID of the dashboard, which must exist, created by CREATE DASHBOARD.
<entityList>
Revoke DELETE privileges on dashboard 740 for the payrollDept role.
Revoke all privileges on dashboard 730 for hrDept role and users dennis and mike.
Revoke EDIT and DELETE of dashboard 740 for the hrDept and accountsPayableDept roles and for users dante and jonathan.
See Also
Common Privilege Levels for Non-Superusers
The following privilege levels are typically recommended for non-superusers in Immerse. Privileges assigned for users in your organization may vary depending on access requirements.
Example: Roles and Privileges
These examples assume that tables table1 through table4 are created as needed:
The following examples show how to work with users, roles, tables, and dashboards.
Create User Accounts
Grant Access to Users on Database
Create Marketing Department Roles
Grant Marketing Department Roles to Marketing Department Employees
Grant Privelege to Marketing Department Roles
Create Sales Department Roles
Grant Sales Department Roles to Sales Department Employees
Grant Privilege to Sales Department Roles
Grant All Sales Roles to Sales Department Manager and Marketing Department Manager
Grant View on Dashboards
Use the \dash command to list all dashboards and their unique IDs in HEAVY.AI:
Here, the Marketing_Summary dashboard uses table2 as a data source. The role marketingDeptRole2 has select privileges on that table. Grant view access on the Marketing_Summary dashboard to marketingDeptRole2:
Relationships Between Users, Roles, and Tables
The following table shows the roles and privileges for each user created in the previous example.
Commands to Report Roles and Privileges
Use the following commands to list current roles and assigned privileges. If you have superuser access, you can see privileges for all users. Otherwise, you can see only those roles and privileges for which you have access.
Results for users, roles, privileges, and object privileges are returned in creation order.
\dash
Lists all dashboards and dashboard IDs in HEAVY.AI. Requires superuser privileges. Dashboard privileges are assigned by dashboard ID because dashboard names may not be unique.
Example
heavysql> \dash database heavyai
Dashboard ID | Dashboard Name | Owner
1 | Marketing_Summary | heavyai
\object_privileges objectType `_objectName`_
Reports all privileges granted to the specified object for all roles and users. If the specified objectName does not exist, no results are reported. Used for databases and tables only.
Example
\privileges roleName | userName
Reports all object privileges granted to the specified role or user. The roleName or userName specified must exist.
Example
\role_list userName
Reports all roles granted to the given user. The userName specified must exist.
Example
\roles
Reports all roles.
Example
\u
Lists all users.
Example
Example: Data Security
The following example demonstrates field-level security using two views:
view_users_limited, in which users only see three of seven fields:userid,First_Name, andDepartment.view_users_full, users see all seven fields.
Source Data

Create Views
Create Users
Grant Access to Users on Database
Create Roles
Grant Roles to Users
Grant Privilege to View Roles
Verify Views
User readonly1 sees no tables, only the specific view granted, and only the three specific columns returned in the view:
User readonly2 sees no tables, only the specific view granted, and all seven columns returned in the view: