> ## Documentation Index
> Fetch the complete documentation index at: https://docs.kinetica.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Security

<a id="sql-security" />

*Kinetica* provides basic table-level role-based access control for users.  It
also allows global read/write and administrative access to be granted.
For details about *Kinetica* security, see [Security Concepts](/content/security/sec_concepts).

<Tip>
  A limited set of user/role information can be extracted via function
  calls.  See [User/Security Functions](/content/sql/query#sql-functions-security) for details.
</Tip>

Security features accessible via SQL include:

* [User Management](/content/sql/security#sql-security-user-mgmt)
* [Role Management](/content/sql/security#sql-security-role-mgmt)
* [Privilege Management](/content/sql/security#sql-security-priv-mgmt)
* [Impersonation (Execute As...)](/content/sql/security#sql-security-impersonation) - enables execution of commands as
  another user

<a id="sql-security-user-mgmt" />

## User Management

The ability to manage user accounts is available through SQL, using the
following commands:

* [CREATE USER](/content/sql/security#sql-security-user-mgmt-create)
* [ALTER USER](/content/sql/security#sql-security-user-mgmt-alter)
* [DROP USER](/content/sql/security#sql-security-user-mgmt-drop)
* [SHOW SECURITY FOR User](/content/sql/security#sql-security-user-mgmt-show)

See [Users](/content/security/sec_concepts#security-concepts-users) for details about users within
*Kinetica*.

<a id="sql-security-user-mgmt-create" />

### CREATE USER

[Users](/content/security/sec_concepts#security-concepts-users) can be added to the system and assigned
[permissions](/content/security/sec_concepts#security-concepts-permissions) either directly or via
[roles](/content/security/sec_concepts#security-concepts-roles).

Optionally, the user can be associated with a
[resource group](/content/rm/concepts#rm-concepts-resource-groups) and/or be assigned a
[default schema](/content/concepts/schemas#schema-default).

```sql title="CREATE USER Syntax" theme={null}
CREATE USER <user name>
[ < [WITH] PASSWORD [=] | IDENTIFIED BY [PASSWORD] > '<user password>' ]
[ [WITH] RESOURCE GROUP [=] <group name> ]
[ [WITH] DEFAULT SCHEMA [=] <schema name> ]
[ [WITH] ACTIVATED [=] <TRUE | FALSE> ]
```

<Info>
  The password needs to be single-quoted and must not contain single quotes.
</Info>

#### Examples

Two of the ways to create a new internal user with the user ID of
**jsmith** and a password of **secret** are:

```sql CREATE USER Example theme={null}
CREATE USER jsmith IDENTIFIED BY 'secret'
CREATE USER jsmith WITH PASSWORD 'secret'
```

To create an internal user with the user ID of **jsmith**, a password of
**secret**, and assigning the **memory\_over\_execution** *resource group*:

```sql CREATE USER with Resource Group Example theme={null}
CREATE USER jsmith
IDENTIFIED BY 'secret'
WITH RESOURCE GROUP memory_over_execution
```

To create a user with an existing external LDAP user, the user name should match
the LDAP user name and be prepended with the `@` symbol; no password is
supplied, as the user will be externally authenticated:

```sql CREATE USER (External) Example theme={null}
CREATE USER "@jsmith"
```

<a id="sql-security-user-mgmt-alter" />

### ALTER USER

Any of the following facets of a [user](/content/security/sec_concepts#security-concepts-users) can be
altered, either individually or as a group:

* password
* [resource group](/content/rm/concepts#rm-concepts-resource-groups)
* [default schema](/content/concepts/schemas#schema-default)

```sql title="ALTER USER Syntax" theme={null}
ALTER USER <user name>
SET
    [ PASSWORD [=] '<user password>' ]
    [ RESOURCE GROUP [=] <group name | DEFAULT> ]
    [ DEFAULT SCHEMA [=] <schema name | DEFAULT> ]
    [ ACTIVATED [=] <TRUE | FALSE> ]
```

<Info>
  The password needs to be single-quoted and must not contain single quotes.
</Info>

#### Examples

To alter a user with the user ID of **jsmith**, assigning a
password of **new\_secret**, and the **memory\_over\_execution** *resource group*:

```sql ALTER USER with Resource Group Example theme={null}
ALTER USER jsmith
SET
    PASSWORD = 'new_secret'
    RESOURCE GROUP memory_over_execution
```

To unassign the **memory\_over\_execution** *resource\_group* from the **jsmith**
user:

```sql ALTER USER Removing Resource Group Example theme={null}
ALTER USER jsmith
SET
    RESOURCE GROUP DEFAULT
```

<a id="sql-security-user-mgmt-drop" />

### DROP USER

Any [user](/content/security/sec_concepts#security-concepts-users), other than the
[default users](/content/security/sec_concepts#security-concepts-users-default), can be removed from the
system.  Note that any database objects created by a user will remain when the
user is removed.

```sql title="DROP USER Syntax" theme={null}
DROP USER <user name>
```

#### Examples

To drop an internal user **jsmith**:

```sql DROP USER (Internal) Example theme={null}
DROP USER jsmith
```

To drop an external LDAP user **jsmith**:

```sql DROP USER (External) Example theme={null}
DROP USER "@jsmith"
```

<a id="sql-security-user-mgmt-show" />

### SHOW SECURITY FOR User

For any one or more (or all) [users](/content/security/sec_concepts#security-concepts-users) in the
system, the following can be listed:

* [permissions](/content/security/sec_concepts#security-concepts-permissions)
* [roles](/content/security/sec_concepts#security-concepts-roles)
* [resource groups](/content/rm/concepts#rm-concepts-resource-groups)
* [default schema](/content/concepts/schemas#schema-default)

In addition, permissions, roles, & resource groups will be listed recursively
for the roles the specified users have and the roles those roles have, etc.
This allows the full set of permissions for a given user, both direct &
inherited, to be viewed with one command.

```sql title="SHOW SECURITY FOR User Syntax" theme={null}
SHOW SECURITY FOR <user name>,...
```

#### Examples

To show the permissions, roles, *resource group*, and
*default schema* for user **jsmith**:

```sql SHOW SECURITY FOR User Example theme={null}
SHOW SECURITY FOR jsmith
```

<a id="sql-security-role-mgmt" />

## Role Management

The ability to manage roles is available through SQL, using the following
commands:

* [CREATE ROLE](#create-role)
* [ALTER ROLE](#alter-role)
* [DROP ROLE](#drop-role)
* [SHOW SECURITY FOR Role](#show-security-for-role)

See [Roles](/content/security/sec_concepts#security-concepts-roles) for details about roles within *Kinetica*.

<a id="sql-security-role-mgmt-create" />

### CREATE ROLE

A new [role](/content/security/sec_concepts#security-concepts-roles) can be created as a container for
[permissions](/content/security/sec_concepts#security-concepts-permissions) or other roles, though both
of those must be granted to the role after its creation.

Optionally, the role can be associated with a
[resource group](/content/rm/concepts#rm-concepts-resource-groups).

```sql title="CREATE ROLE Syntax" theme={null}
CREATE ROLE <role name>
[ [WITH] RESOURCE GROUP [=] <group name> ]
```

#### Examples

To create an **analyst** role:

```sql CREATE ROLE Example theme={null}
CREATE ROLE analyst
```

To create an **executive** role, assigning it the **execution\_over\_memory**
*resource group*:

```sql CREATE ROLE with Resource Group Example theme={null}
CREATE ROLE executive
WITH RESOURCE GROUP execution_over_memory
```

### ALTER ROLE

A [role](/content/security/sec_concepts#security-concepts-roles) can have its associated
[resource group](/content/rm/concepts#rm-concepts-resource-groups) modified.

```sql title="ALTER ROLE Syntax" theme={null}
ALTER ROLE <role name>
SET RESOURCE GROUP [=] <group name | DEFAULT>
```

#### Examples

To assign the **memory\_over\_execution** *resource group* to the **analyst**
role:

```sql ALTER ROLE Example theme={null}
ALTER ROLE analyst
SET RESOURCE GROUP memory_over_execution
```

To unassign the *resource group* from the **analyst** role:

```sql ALTER ROLE Removing Resource Group Example theme={null}
ALTER ROLE analyst
SET RESOURCE GROUP DEFAULT
```

### DROP ROLE

Dropping a [role](/content/security/sec_concepts#security-concepts-roles) will remove the associated
[permissions](/content/security/sec_concepts#security-concepts-permissions) & roles granted through the
role to all [users](/content/security/sec_concepts#security-concepts-users) with the role.  Users & roles
granted the same permissions either directly or via other roles will retain
those permissions.

Any role, other than the [default roles](/content/security/sec_concepts#security-concepts-roles-default),
can be removed from the system.

```sql title="DROP ROLE Syntax" theme={null}
DROP ROLE <role name>
```

#### Examples

To drop the **analyst** role:

```sql DROP ROLE Example theme={null}
DROP ROLE analyst
```

### SHOW SECURITY FOR Role

For any one or more (or all) [roles](/content/security/sec_concepts#security-concepts-roles) in the
system, the following can be listed:

* [permissions](/content/security/sec_concepts#security-concepts-permissions)
* [roles](/content/security/sec_concepts#security-concepts-roles)
* [resource groups](/content/rm/concepts#rm-concepts-resource-groups)

In addition, these attributes will be listed recursively for the roles the
specified roles have and the roles those roles have, etc.  This allows the full
set of permissions for a given role, both direct & inherited, to be viewed with
one command.

```sql title="SHOW SECURITY FOR Role Syntax" theme={null}
SHOW SECURITY FOR <role name>,...
```

#### Examples

To show the permissions, roles, and *resource group* for the **analyst** role:

```sql SHOW SECURITY FOR Role Example theme={null}
SHOW SECURITY FOR analyst
```

<a id="sql-security-priv-mgmt" />

## Privilege Management

The ability to manage user & role privileges is available through SQL, using the
following commands:

* Roles ([GRANT](/content/sql/security#sql-security-priv-mgmt-role-grant) | [REVOKE](/content/sql/security#sql-security-priv-mgmt-role-revoke))
* System Permissions ([GRANT](/content/sql/security#sql-security-priv-mgmt-sys-grant) | [REVOKE](/content/sql/security#sql-security-priv-mgmt-sys-revoke))
* Schema Permissions ([GRANT](/content/sql/security#sql-security-priv-mgmt-schema-grant) | [REVOKE](/content/sql/security#sql-security-priv-mgmt-schema-revoke))
* Table Permissions ([GRANT](/content/sql/security#sql-security-priv-mgmt-table-grant) | [REVOKE](/content/sql/security#sql-security-priv-mgmt-table-revoke))
* Credential Permissions ([GRANT](/content/sql/security#sql-security-priv-mgmt-cred-grant) | [REVOKE](/content/sql/security#sql-security-priv-mgmt-cred-revoke))
* Data Source Permissions ([GRANT](/content/sql/security#sql-security-priv-mgmt-ds-grant) | [REVOKE](/content/sql/security#sql-security-priv-mgmt-ds-revoke))
* Data Sink Permissions ([GRANT](/content/sql/security#sql-security-priv-mgmt-dsink-grant) | [REVOKE](/content/sql/security#sql-security-priv-mgmt-dsink-revoke))
* Directory Permissions ([GRANT](/content/sql/security#sql-security-priv-mgmt-dir-grant) | [REVOKE](/content/sql/security#sql-security-priv-mgmt-dir-revoke))
* Function Permissions ([GRANT](/content/sql/security#sql-security-priv-mgmt-udf-grant) | [REVOKE](/content/sql/security#sql-security-priv-mgmt-udf-revoke))
* Graph Permissions ([GRANT](/content/sql/security#sql-security-priv-mgmt-graph-grant) | [REVOKE](/content/sql/security#sql-security-priv-mgmt-graph-revoke))
* Procedure Permissions ([GRANT](/content/sql/security#sql-security-priv-mgmt-sqlp-grant) | [REVOKE](/content/sql/security#sql-security-priv-mgmt-sqlp-revoke))
* SQL-GPT Context Permissions ([GRANT](/content/sql/security#sql-security-priv-mgmt-gpt-grant) | [REVOKE](/content/sql/security#sql-security-priv-mgmt-gpt-revoke))
* Stream Permissions ([GRANT](/content/sql/security#sql-security-priv-mgmt-stream-grant) | [REVOKE](/content/sql/security#sql-security-priv-mgmt-stream-revoke))
* [SHOW SECURITY](/content/sql/security#sql-security-show)
* [CHECK](/content/sql/security#sql-security-check)

See [Users](/content/security/sec_concepts#security-concepts-users) for details about user accounts within
*Kinetica*.

<a id="sql-security-priv-mgmt-role-grant" />

### GRANT Role

[Roles](/content/security/sec_concepts#security-concepts-roles) can be granted directly to
[users](/content/security/sec_concepts#security-concepts-users) or other roles.

```sql title="GRANT Role Syntax" theme={null}
GRANT <role name> TO <user name | role name>
```

#### Examples

To grant a role allowing access to analyst tables to the
**analyst** role, and then grant that **analyst** role to user **jsmith**:

```sql GRANT ROLE Example theme={null}
GRANT analyst_table_access TO analyst
GRANT analyst TO jsmith
```

<a id="sql-security-priv-mgmt-sys" />

<a id="sql-security-priv-mgmt-sys-grant" />

### GRANT SYSTEM Permission

[System permissions](/content/security/sec_concepts#security-concepts-permissions-system) can be
granted directly to [users](/content/security/sec_concepts#security-concepts-users) or
[roles](/content/security/sec_concepts#security-concepts-roles).

<a id="sql-perm-system-admin" />

#### System Administration

```sql title="GRANT System Administrative Permission Syntax" theme={null}
GRANT SYSTEM ADMIN TO <user name | role name>
```

| Permission     | Description                                                                    |
| -------------- | ------------------------------------------------------------------------------ |
| `SYSTEM ADMIN` | [System administrator permission](/content/security/sec_concepts#system-admin) |

<a id="sql-perm-system-mgmt" />

#### System Management

```sql title="GRANT System Management Permission Syntax" theme={null}
GRANT SYSTEM < CREATE | MONITOR | READ | WRITE > TO <user name | role name> [WITH GRANT OPTION]
```

| Permission          | Description                                                                                                                                   |
| ------------------- | --------------------------------------------------------------------------------------------------------------------------------------------- |
| `SYSTEM CREATE`     | [System create permission](/content/security/sec_concepts#system-create)                                                                      |
| `SYSTEM MONITOR`    | [System monitor permission](/content/security/sec_concepts#system-monitor)                                                                    |
| `SYSTEM READ`       | [System read permission](/content/security/sec_concepts#system-read)                                                                          |
| `SYSTEM WRITE`      | [System write permission](/content/security/sec_concepts#system-write)                                                                        |
| `WITH GRANT OPTION` | Grant this permission with a [grant option](/content/security/sec_concepts#security-concepts-permissions-grant-option) to grant it to others. |

<a id="sql-perm-user-admin" />

#### User Administration

```sql title="GRANT User Administrative Permission Syntax" theme={null}
GRANT USER ADMIN TO <user name | role name>
```

| Permission   | Description                                                                |
| ------------ | -------------------------------------------------------------------------- |
| `USER ADMIN` | [User administrator permission](/content/security/sec_concepts#user-admin) |

<a id="sql-perm-create-dir" />

#### Create Directory

```sql title="GRANT KiFS Directory Create Permission Syntax" theme={null}
GRANT CREATE DIRECTORY TO <user name | role name> [WITH GRANT OPTION]
```

| Permission          | Description                                                                                                                                   |
| ------------------- | --------------------------------------------------------------------------------------------------------------------------------------------- |
| `CREATE DIRECTORY`  | [Create directory permission](/content/security/sec_concepts#directory-create)                                                                |
| `WITH GRANT OPTION` | Grant this permission with a [grant option](/content/security/sec_concepts#security-concepts-permissions-grant-option) to grant it to others. |

<a id="sql-perm-create-udf" />

#### Create UDF/UDTF

```sql title="GRANT UDF Create Permission Syntax" theme={null}
GRANT CREATE FUNCTION TO <user name | role name> [WITH GRANT OPTION]
```

| Permission          | Description                                                                                                                                   |
| ------------------- | --------------------------------------------------------------------------------------------------------------------------------------------- |
| `CREATE FUNCTION`   | [Create UDF/UDTF permission](/content/security/sec_concepts#proc-create)                                                                      |
| `WITH GRANT OPTION` | Grant this permission with a [grant option](/content/security/sec_concepts#security-concepts-permissions-grant-option) to grant it to others. |

#### Examples

To grant system administrator permission to **jsmith**:

```sql GRANT SYSTEM ADMIN Example theme={null}
GRANT SYSTEM ADMIN TO jsmith
```

To grant read access to all tables to the **auditor** role:

```sql GRANT SYSTEM READ Example theme={null}
GRANT SYSTEM READ TO auditor
```

To grant user administrator permission to **jsmith**:

```sql GRANT USER ADMIN Example theme={null}
GRANT USER ADMIN TO jsmith
```

<a id="sql-security-priv-mgmt-schema" />

<a id="sql-security-priv-mgmt-schema-grant" />

### GRANT Schema Permission

[Schema permissions](/content/security/sec_concepts#security-concepts-permissions-schema), which
allow management of [schemas](/content/sql/ddl#sql-create-schema) and their
contained objects can be granted directly to
[users](/content/security/sec_concepts#security-concepts-users) or
[roles](/content/security/sec_concepts#security-concepts-roles).

```sql title="GRANT Schema Permission Syntax" theme={null}
GRANT < SELECT | INSERT | UPDATE | DELETE | CREATE <object type> | ALL > [PRIVILEGES]
ON [SCHEMA] <schema reference>
TO <user name | role name>
[WITH GRANT OPTION]
```

#### Parameters

<AccordionGroup>
  <Accordion title="PRIVILEGES" id="privileges" defaultOpen>
    Optional keyword for SQL-92 compatibility.
  </Accordion>

  <Accordion title="SCHEMA" id="schema" defaultOpen>
    Optional keyword to avoid ambiguity between a grant to a schema and a grant to a
    table/view in the user's default schema.
  </Accordion>

  <Accordion title="<schema reference>" id="<schema-reference>" defaultOpen>
    Either the name of the schema to which access is being granted or a wildcard expression
    signifying the schema(s) and table(s)/views(s) to which access is being granted.

    <div>
      <table class="table w-full [&_td]:min-w-[150px] [&_th]:text-left [&_td[data-numeric]]:tabular-nums">
        <thead>
          <tr>
            <th>Wildcard Form</th>
            <th>Selected Objects</th>
          </tr>
        </thead>

        <tbody>
          <tr>
            <td><code>\*</code></td>
            <td>All schemas currently in the database</td>
          </tr>

          <tr>
            <td><code>*.*</code></td>
            <td>All schemas, tables, & views currently in the database</td>
          </tr>
        </tbody>
      </table>
    </div>
  </Accordion>

  <Accordion title="<object type>" id="<object-type>" defaultOpen>
    For granting `CREATE` privilege, the object type to give permission to create in the
    given schema.

    Supported object types include:

    <div>
      <table class="table w-full [&_td]:min-w-[150px] [&_th]:text-left [&_td[data-numeric]]:tabular-nums">
        <thead>
          <tr>
            <th>Target Type</th>
            <th>Description</th>
          </tr>
        </thead>

        <tbody>
          <tr>
            <td><code>CONTEXT</code></td>
            <td>[SQL-GPT context](/content/sql/sqlgpt#sql-gpt-create-context) object</td>
          </tr>

          <tr>
            <td><code>CREDENTIAL</code></td>
            <td>[Credential](/content/sql/ddl#sql-create-credential) object</td>
          </tr>

          <tr>
            <td><code>DATA SINK</code></td>
            <td>External [data sink](/content/sql/ddl#sql-create-data-sink)</td>
          </tr>

          <tr>
            <td><code>DATA SOURCE</code></td>
            <td>External [data source](/content/sql/ddl#sql-create-data-source)</td>
          </tr>

          <tr>
            <td><code>GRAPH</code></td>
            <td>[Graph](/content/sql/graph#sql-graph-create)</td>
          </tr>

          <tr>
            <td><code>PROCEDURE</code></td>
            <td>SQL [stored procedure](/content/sql/procedure#sql-procedures)</td>
          </tr>

          <tr>
            <td><code>STREAM</code></td>
            <td>[Stream](/content/sql/ddl#sql-create-stream)</td>
          </tr>

          <tr>
            <td><code>TABLE</code></td>
            <td>[Table](/content/sql/ddl#sql-create-table) (or view)</td>
          </tr>
        </tbody>
      </table>
    </div>
  </Accordion>

  <Accordion title="WITH GRANT OPTION" id="with-grant-option" defaultOpen>
    Grant this permission with a
    [grant option](/content/security/sec_concepts#security-concepts-permissions-grant-option) to grant it to others.
  </Accordion>
</AccordionGroup>

<Info>
  The `ALL` permission corresponds to the native
  [table\_admin](/content/security/sec_concepts#security-concepts-permissions-schema) permission,
  which gives full read/write access as well as the additional permission to
  `CREATE`, `ALTER`, & `DROP` any table or view in the specified
  schema(s).
</Info>

#### Examples

To grant `SELECT` access on all schemas to the **auditor** role:

```sql GRANT Read on Schemas to Role Example theme={null}
GRANT SELECT ON * TO auditor
```

To grant `SELECT` access on all current and future tables & views within the
**app\_schema** schema to the **app\_user** role:

```sql GRANT Read on Schema to Role Example theme={null}
GRANT SELECT ON app_schema TO app_user
```

To grant full access on each of the schemas, tables, & views in the database
individually to the **dbadmin** role:

```sql GRANT All Permissions on All Schemas/Tables/Views to Role Example theme={null}
GRANT ALL ON *.* TO dbadmin
```

<a id="sql-security-priv-mgmt-table" />

<a id="sql-security-priv-mgmt-table-grant" />

### GRANT Table Permission

[Table permissions](/content/security/sec_concepts#security-concepts-permissions-table), which can
be applied to tables and views, can be granted directly to
[users](/content/security/sec_concepts#security-concepts-users) or
[roles](/content/security/sec_concepts#security-concepts-roles).

<Note>
  For granting the ability to create *tables*, see
  [GRANT Schema Permission](/content/sql/security#sql-security-priv-mgmt-schema-grant).
</Note>

[Row-level security](/content/security/sec_concepts#sec-concepts-perm-table-row) can be invoked for
`SELECT` privilege by specifying a `WHERE` clause expression.

[Column-level security](/content/security/sec_concepts#sec-concepts-perm-table-col) can be invoked for
`SELECT` privilege by specifying a list of accessible columns and/or
[column security functions](/content/security/sec_concepts#sec-concepts-perm-table-col-func).

```sql title="GRANT Table Permission Syntax" theme={null}
GRANT < SELECT | INSERT | UPDATE | DELETE | ALL > [PRIVILEGES]
[ON [TABLE] <object reference> [<column list>]]
TO <user name | role name>
[WHERE <expression>]
[WITH GRANT OPTION]
```

#### Parameters

<AccordionGroup>
  <Accordion title="PRIVILEGES" id="privileges-2" defaultOpen>
    Optional keyword for SQL-92 compatibility.
  </Accordion>

  <Accordion title="ON" id="on" defaultOpen>
    Optional object specifier for granting permission to a specific object or set of objects.
    If not specified, then the grant will be for all tables and views
    in all schemas now and in the future
  </Accordion>

  <Accordion title="TABLE" id="table" defaultOpen>
    Optional keyword for SQL-92 compatibility, and to avoid ambiguity between a grant to a
    table/view in the user's default schema (when `<schema name>` is omitted) and a grant
    to a schema.
  </Accordion>

  <Accordion title="<object reference>" id="<object-reference>" defaultOpen>
    The name of the table/view and/or schema to which access is being granted.
    the following forms are valid:

    <div>
      <table class="table w-full [&_td]:min-w-[150px] [&_th]:text-left [&_td[data-numeric]]:tabular-nums">
        <thead>
          <tr>
            <th>Form</th>
            <th>Selected Objects</th>
          </tr>
        </thead>

        <tbody>
          <tr>
            <td>*\<schema>.\<object>*</td>
            <td>Fully-qualified table or view name in the specified schema</td>
          </tr>

          <tr>
            <td><code>*.*</code></td>
            <td>All existing tables & views that the granting user can see across all schemas</td>
          </tr>

          <tr>
            <td><code>\*</code></td>
            <td>All existing schemas that the granting user can see, which will grant access to all tables and views in those schemas now and in the future</td>
          </tr>

          <tr>
            <td>*\<schema>*</td>
            <td>All tables and views in the specified schema now and in the future</td>
          </tr>

          <tr>
            <td>*\<object>*</td>
            <td>Table or view in the default schema.  If a schema exists with the same name, it will be used.  To avoid this, specify the fully-qualified object name.</td>
          </tr>
        </tbody>
      </table>
    </div>
  </Accordion>

  <Accordion title="<column list>" id="<column-list>" defaultOpen>
    Optional comma-separated list of specific table columns and/or
    [column security functions](/content/security/sec_concepts#sec-concepts-perm-table-col-func) applied to columns
    on which to grant access; see [Column-Level Security](/content/security/sec_concepts#sec-concepts-perm-table-col) for details.
  </Accordion>

  <Accordion title="WHERE <expression>" id="where-<expression>" defaultOpen>
    Optional filter expression on the table to which access is being granted, determining to
    which rows of the target table the grantee will be given access; see
    [Row-Level Security](/content/security/sec_concepts#sec-concepts-perm-table-row) for details.
  </Accordion>

  <Accordion title="WITH GRANT OPTION" id="with-grant-option-2" defaultOpen>
    Grant this permission with a
    [grant option](/content/security/sec_concepts#security-concepts-permissions-grant-option) to grant it to others.

    <Info>
      `WITH GRANT OPTION` is not allowed when also granting with row or column
      restrictions.
    </Info>
  </Accordion>
</AccordionGroup>

<Info>
  The `ALL` permission corresponds to the native
  [table\_admin](/content/security/sec_concepts#security-concepts-permissions-table) permission, which
  gives full read/write access as well as the additional permission either to
  `ALTER` and `DROP` the specified table.
</Info>

#### Examples

For example, to grant full access on the **network\_config** table to **jsmith**:

```sql GRANT All Permissions on Table to User Example theme={null}
GRANT ALL PRIVILEGES ON TABLE example.network_config TO jsmith
```

To grant `SELECT` access on the **network\_config\_history** table to the
**analyst** role:

```sql GRANT Read on Table to Role Example theme={null}
GRANT SELECT ON example.network_config_history TO analyst
```

To grant full access on each of the tables & views within the
**example** schema to the **developer** role:

```sql GRANT All Permissions on Current Tables/Views in Schema to Role Example theme={null}
GRANT ALL ON example.* TO developer
```

<a id="sql-security-priv-mgmt-row-grant" />

#### Row-Level Security Examples

To grant `SELECT` access on an **rx\_order** table for all orders placed since
the year **2002**:

```sql GRANT Row-Level Access by Filter Example theme={null}
GRANT SELECT ON example.rx_order
	TO zanalyst
	WHERE order_ts >= '2002-01-01'
```

To grant `SELECT` access on an **rx\_order** table for only orders belonging
to the current user:

```sql GRANT Row-Level Access Tied to Current User Example theme={null}
GRANT SELECT ON example.rx_order
	TO rx_user
	WHERE name = USER()
```

<a id="sql-security-priv-mgmt-col-grant" />

#### Column-Level Security Examples

To grant `SELECT` access on the following columns of an **rx\_order** table:

* obfuscated version of the orderer's social security number
* name of the prescription ordered
* order date/time

```sql GRANT Obfuscated Column-Level Access Example theme={null}
GRANT SELECT ON example.rx_order(HASH(ssn), rx_name, order_ts) TO zanalyst
```

To grant `SELECT` access on the following columns of an **rx\_order** table:

* masked version of the orderer's social security number (last 4 digits)
* name of the orderer
* name of the prescription ordered
* order date/time

```sql GRANT Masked Column-Level Access Example theme={null}
GRANT SELECT ON example.rx_order(MASK(ssn, 1, 6), name, rx_name, order_ts) TO rx_user
```

<a id="sql-security-priv-mgmt-cred-grant" />

### GRANT Credential Permission

[Credential permissions](/content/security/sec_concepts#security-concepts-permissions-credential),
which allow management of [credentials](/content/sql/ddl#sql-create-credential),
can be granted directly to
[users](/content/security/sec_concepts#security-concepts-users) or
[roles](/content/security/sec_concepts#security-concepts-roles).

<Note>
  For granting the ability to create *credentials*, see
  [GRANT Schema Permission](/content/sql/security#sql-security-priv-mgmt-schema-grant).
</Note>

```sql title="GRANT Credential Permission Syntax" theme={null}
GRANT <READ | ADMIN> ON CREDENTIAL <credential name> TO <user name | role name> [WITH GRANT OPTION]
```

| Permission          | Description                                                                                                                                   |
| ------------------- | --------------------------------------------------------------------------------------------------------------------------------------------- |
| `ADMIN`             | Modify or drop the given *credential* (includes `READ` access).                                                                               |
| `READ`              | Use or view the configuration of the given *credential*.                                                                                      |
| `WITH GRANT OPTION` | Grant this permission with a [grant option](/content/security/sec_concepts#security-concepts-permissions-grant-option) to grant it to others. |

#### Examples

To grant read access on the *credential* named
**auser\_azure\_active\_dir\_creds** to the **auser** *user*:

```sql GRANT Credential Use Permission Example theme={null}
GRANT READ ON CREDENTIAL auser_azure_active_dir_creds TO auser
```

To grant administrative access on the *credential* to the **auser** *user*:

```sql GRANT Credential Administrative Permission Example theme={null}
GRANT ADMIN ON CREDENTIAL auser_azure_active_dir_creds TO auser
```

<a id="sql-security-priv-mgmt-ds-grant" />

### GRANT Data Source Permission

[Data source permissions](/content/security/sec_concepts#security-concepts-permissions-datasource),
which allow management of [data sources](/content/sql/ddl#sql-create-data-source),
can be granted directly to
[users](/content/security/sec_concepts#security-concepts-users) or
[roles](/content/security/sec_concepts#security-concepts-roles).

<Note>
  For granting the ability to create *data sources*, see
  [GRANT Schema Permission](/content/sql/security#sql-security-priv-mgmt-schema-grant).
</Note>

```sql title="GRANT Data Source Permission Syntax" theme={null}
GRANT <CONNECT | ADMIN> ON DATA SOURCE <data source name> TO <user name | role name> [WITH GRANT OPTION]
```

| Permission          | Description                                                                                                                                   |
| ------------------- | --------------------------------------------------------------------------------------------------------------------------------------------- |
| `ADMIN`             | Modify or drop the given *data source* (includes `CONNECT` access).                                                                           |
| `CONNECT`           | Connect to, load data into, or view the configuration of the given *data source*.                                                             |
| `WITH GRANT OPTION` | Grant this permission with a [grant option](/content/security/sec_concepts#security-concepts-permissions-grant-option) to grant it to others. |

#### Examples

To grant connect access on the *data source* named
**kin\_ds** to the **auser** *user*:

```sql GRANT Data Source Use Permission Example theme={null}
GRANT CONNECT ON DATA SOURCE kin_ds TO auser
```

To grant administrative access on the *data source* named **kin\_ds\_anon** to the
**auser** *user*:

```sql GRANT Data Source Administrative Permission Example theme={null}
GRANT ADMIN ON DATA SOURCE kin_ds_anon TO auser
```

<a id="sql-security-priv-mgmt-dsink-grant" />

### GRANT Data Sink Permission

[Data sink permissions](/content/security/sec_concepts#security-concepts-permissions-datasink),
which allow management of [data sinks](/content/sql/ddl#sql-create-data-sink),
can be granted directly to
[users](/content/security/sec_concepts#security-concepts-users) or
[roles](/content/security/sec_concepts#security-concepts-roles).

<Note>
  For granting the ability to create *data sinks*, see
  [GRANT Schema Permission](/content/sql/security#sql-security-priv-mgmt-schema-grant).
</Note>

```sql title="GRANT Data Sink Permission Syntax" theme={null}
GRANT <CONNECT | ADMIN> ON DATA SINK <data sink name> TO <user name | role name> [WITH GRANT OPTION]
```

| Permission          | Description                                                                                                                                   |
| ------------------- | --------------------------------------------------------------------------------------------------------------------------------------------- |
| `ADMIN`             | Modify or drop the given *data sink* (includes `CONNECT` access).                                                                             |
| `CONNECT`           | Connect to, load data into, or view the configuration of the given *data sink*.                                                               |
| `WITH GRANT OPTION` | Grant this permission with a [grant option](/content/security/sec_concepts#security-concepts-permissions-grant-option) to grant it to others. |

#### Examples

To grant connect & load access on the *data sink* named
**kin\_dsink** to the **auser** *user*:

```sql GRANT Data Sink Use Permission Example theme={null}
GRANT CONNECT ON DATA SINK kin_dsink TO auser
```

To grant administrative access on the *data sink* named **kin\_dsink\_http** to the
**auser** *user*:

```sql GRANT Data Sink Administrative Permission Example theme={null}
GRANT ADMIN ON DATA SINK kin_dsink_http TO auser
```

<a id="sql-security-priv-mgmt-dir-grant" />

### GRANT Directory Permission

[KiFS directory permissions](/content/security/sec_concepts#security-concepts-permissions-kifs),
which allow management of *files* within
[KiFS directories](/content/sql/kifs#sql-kifs-create-dir), can be granted
directly to [users](/content/security/sec_concepts#security-concepts-users) or
[roles](/content/security/sec_concepts#security-concepts-roles).

<Note>
  For granting the ability to create *directories*, see
  [GRANT SYSTEM Permission](/content/sql/security#sql-security-priv-mgmt-sys-grant).
</Note>

```sql title="GRANT Directory Permission Syntax" theme={null}
GRANT <READ | WRITE> ON DIRECTORY <directory name> TO <user name | role name> [WITH GRANT OPTION]
```

| Permission          | Description                                                                                                                                   |
| ------------------- | --------------------------------------------------------------------------------------------------------------------------------------------- |
| `READ`              | List, download, or load data from *files* within the given *directory*.                                                                       |
| `WRITE`             | Upload *files* to or delete *files* from the given *directory* (includes `READ` access).                                                      |
| `WITH GRANT OPTION` | Grant this permission with a [grant option](/content/security/sec_concepts#security-concepts-permissions-grant-option) to grant it to others. |

#### Examples

To grant read access on a *directory* named **kdata** to the
**kuser** *user*:

```sql GRANT Directory Read Permission Example theme={null}
GRANT READ ON DIRECTORY 'kdata' TO kuser
```

To grant write access on a *directory* named **kdata** to the **kuser** *user*:

```sql GRANT Directory Write Permission Example theme={null}
GRANT WRITE ON DIRECTORY 'kdata' TO kuser
```

<a id="sql-security-priv-mgmt-udf-grant" />

### GRANT Function (UDF/UDTF) Permission

[Function permissions](/content/security/sec_concepts#security-concepts-permissions-function),
which allow management of [UDFs/UDTFs](/content/sql/udf#sql-udf), can be granted
directly to [users](/content/security/sec_concepts#security-concepts-users) or
[roles](/content/security/sec_concepts#security-concepts-roles).

<Note>
  For granting the ability to create *UDFs/UDTFs*, see
  [GRANT SYSTEM Permission](/content/sql/security#sql-security-priv-mgmt-sys-grant).
</Note>

```sql title="GRANT FUNCTION (UDF) Permission Syntax" theme={null}
GRANT <EXECUTE | ADMIN> ON FUNCTION < <function name> | * > TO <user name | role name> [WITH GRANT OPTION]
```

| Permission          | Description                                                                                                                                                                                                                                                            |
| ------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `ADMIN`             | Drop the given *UDF*, and display full configuration about it (includes `EXECUTE` access). <br /> <br /> When `*` is used instead of *function name*, gives permission to manage [Python UDF function environments](/content/sql/udf#sql-create-function-environment). |
| `EXECUTE`           | Run and terminate the given *UDF*, and display limited configuration about it.                                                                                                                                                                                         |
| `WITH GRANT OPTION` | Grant this permission with a [grant option](/content/security/sec_concepts#security-concepts-permissions-grant-option) to grant it to others.                                                                                                                          |

<Info>
  Use `*` instead of *function name* to grant the specified permission
  to all existing & future UDFs.
</Info>

#### Examples

To grant execute on the **udf\_sos\_py\_proc** *UDF* to **udf\_user**:

```sql GRANT Function Execute Permission Example theme={null}
GRANT EXECUTE ON FUNCTION UDF_SOS_PY_PROC TO udf_user
```

To grant administrative access on every existing & future *UDF*, as well as the
ability to manage Python UDF environments, to **udf\_user**:

```sql GRANT Function Administrative Permission Example theme={null}
GRANT ADMIN ON FUNCTION * TO udf_user
```

<a id="sql-security-priv-mgmt-graph-grant" />

### GRANT Graph Permission

[Graph permissions](/content/security/sec_concepts#security-concepts-permissions-graph), which
allow management of [graphs](/content/sql/graph), can be granted
directly to [users](/content/security/sec_concepts#security-concepts-users) or
[roles](/content/security/sec_concepts#security-concepts-roles).

<Note>
  For granting the ability to create *graphs*, see
  [GRANT Schema Permission](/content/sql/security#sql-security-priv-mgmt-schema-grant).
</Note>

```sql title="GRANT Graph Permission Syntax" theme={null}
GRANT <READ | WRITE | ADMIN> ON GRAPH <graph name> TO <user name | role name> [WITH GRANT OPTION]
```

| Permission          | Description                                                                                                                                   |
| ------------------- | --------------------------------------------------------------------------------------------------------------------------------------------- |
| `ADMIN`             | Drop the given *graph* (includes `WRITE` access).                                                                                             |
| `READ`              | Query, match, solve, & show the given *graph*.                                                                                                |
| `WRITE`             | Modify the given *graph* (includes `READ` access).                                                                                            |
| `WITH GRANT OPTION` | Grant this permission with a [grant option](/content/security/sec_concepts#security-concepts-permissions-grant-option) to grant it to others. |

#### Examples

To grant query, match, solve, & show access on the *graph* named
**big\_cities\_graph** to **geo\_user**:

```sql GRANT Graph Permission Example theme={null}
GRANT READ ON GRAPH big_cities_graph TO geo_user
```

<a id="sql-security-priv-mgmt-sqlp-grant" />

### GRANT Procedure Permission

[Procedure permissions](/content/security/sec_concepts#security-concepts-permissions-procedure),
which allow execution of [SQL procedures](/content/sql/procedure#sql-procedures), can be
granted directly to [users](/content/security/sec_concepts#security-concepts-users) or
[roles](/content/security/sec_concepts#security-concepts-roles).

<Note>
  For granting the ability to create *SQL procedures*, see
  [GRANT Schema Permission](/content/sql/security#sql-security-priv-mgmt-schema-grant).
</Note>

```sql title="GRANT EXECUTE PROCEDURE Permission Syntax" theme={null}
GRANT EXECUTE PROCEDURE ON <procedure name> TO <user name | role name> [WITH GRANT OPTION]
```

| Permission          | Description                                                                                                                                   |
| ------------------- | --------------------------------------------------------------------------------------------------------------------------------------------- |
| `EXECUTE`           | Run the given *SQL procedure*.                                                                                                                |
| `WITH GRANT OPTION` | Grant this permission with a [grant option](/content/security/sec_concepts#security-concepts-permissions-grant-option) to grant it to others. |

#### Examples

To grant execute on the **sqlp\_weekly** procedure to **spuser**:

```sql GRANT EXECUTE PROCEDURE Permission Example theme={null}
GRANT EXECUTE PROCEDURE ON example.sqlp_weekly TO spuser
```

<a id="sql-security-priv-mgmt-gpt-grant" />

### GRANT SQL-GPT Context Permission

[SQL-GPT](/content/sql-gpt/concepts) *context permissions*,
which allow management of
[SQL-GPT contexts](/content/sql/sqlgpt#sql-gpt-create-context),
can be granted directly to
[users](/content/security/sec_concepts#security-concepts-users) or
[roles](/content/security/sec_concepts#security-concepts-roles).

<Note>
  For granting the ability to create *SQL-GPT contexts*, see
  [GRANT Schema Permission](/content/sql/security#sql-security-priv-mgmt-schema-grant).
</Note>

```sql title="GRANT SQL-GPT Context Permission Syntax" theme={null}
GRANT <READ | ADMIN> ON CONTEXT <context name> TO <user name | role name> [WITH GRANT OPTION]
```

| Permission          | Description                                                                                                                                   |
| ------------------- | --------------------------------------------------------------------------------------------------------------------------------------------- |
| `ADMIN`             | Modify or drop the given *context* (includes `READ` access).                                                                                  |
| `READ`              | Use the given *context* to generate SQL using a SQL-GPT query.                                                                                |
| `WITH GRANT OPTION` | Grant this permission with a [grant option](/content/security/sec_concepts#security-concepts-permissions-grant-option) to grant it to others. |

#### Examples

To grant *read* access on the *SQL-GPT context* named
**example.atc\_ctx** to the **ctxuser** *user*:

```sql GRANT SQL-GPT Context Permission Example theme={null}
GRANT READ ON CONTEXT example.atc_ctx TO ctxuser
```

<a id="sql-security-priv-mgmt-stream-grant" />

### GRANT Stream Permission

[Stream permissions](/content/security/sec_concepts#security-concepts-permissions-monitor),
which allow removal & display of [streams](/content/sql/ddl#sql-create-stream),
can be granted directly to
[users](/content/security/sec_concepts#security-concepts-users) or
[roles](/content/security/sec_concepts#security-concepts-roles).

<Note>
  For granting the ability to create *streams*, see
  [GRANT Schema Permission](/content/sql/security#sql-security-priv-mgmt-schema-grant).
</Note>

```sql title="GRANT Stream Administrative Permission Syntax" theme={null}
GRANT ADMIN ON STREAM <stream name> TO <user name | role name> [WITH GRANT OPTION]
```

| Permission          | Description                                                                                                                                   |
| ------------------- | --------------------------------------------------------------------------------------------------------------------------------------------- |
| `ADMIN`             | Drop the given *stream*.                                                                                                                      |
| `WITH GRANT OPTION` | Grant this permission with a [grant option](/content/security/sec_concepts#security-concepts-permissions-grant-option) to grant it to others. |

#### Examples

To grant administrative access on the *stream* named
**kin\_stream** to the **auser** *user*:

```sql GRANT Stream Administrative Permission Example theme={null}
GRANT ADMIN ON STREAM example.kin_stream TO auser
```

<a id="sql-security-priv-mgmt-role-revoke" />

### REVOKE Role

[Roles](/content/security/sec_concepts#security-concepts-roles) can be revoked from
[users](/content/security/sec_concepts#security-concepts-users) or other roles.

```sql title="REVOKE Role Syntax" theme={null}
REVOKE <role name> FROM <user name | role name>
```

#### Examples

To revoke a role allowing access to analyst tables from the **analyst** role:

```sql REVOKE Role from Role Example theme={null}
REVOKE analyst_table_access FROM analyst
```

To revoke the **analyst** role from user **jsmith**:

```sql REVOKE Role from User Example theme={null}
REVOKE analyst FROM jsmith
```

<a id="sql-security-priv-mgmt-sys-revoke" />

### REVOKE SYSTEM Permission

[System permissions](/content/security/sec_concepts#security-concepts-permissions-system) can be
revoked from [users](/content/security/sec_concepts#security-concepts-users) or
[roles](/content/security/sec_concepts#security-concepts-roles).

```sql title="REVOKE System Administrative Permission Syntax" theme={null}
REVOKE SYSTEM < ADMIN | CREATE | MONITOR | READ | WRITE > FROM <user name | role name>
```

```sql title="REVOKE User Administrative Permission Syntax" theme={null}
REVOKE USER ADMIN FROM <user name | role name>
```

```sql title="REVOKE KiFS Directory Create Permission Syntax" theme={null}
REVOKE CREATE DIRECTORY FROM <user name | role name>
```

```sql title="REVOKE UDF Create Permission Syntax" theme={null}
REVOKE CREATE FUNCTION FROM <user name | role name>
```

#### Examples

To revoke system administrator permission from **jsmith**:

```sql REVOKE SYSTEM ADMIN Example theme={null}
REVOKE SYSTEM ADMIN FROM jsmith
```

To revoke read access to all tables from the **auditor** role:

```sql REVOKE SYSTEM READ Example theme={null}
REVOKE SYSTEM READ FROM auditor
```

To revoke user administrator permission from **jsmith**:

```sql REVOKE USER ADMIN Example theme={null}
REVOKE USER ADMIN FROM jsmith
```

<a id="sql-security-priv-mgmt-schema-revoke" />

### REVOKE Schema Permission

[Schema permissions](/content/security/sec_concepts#security-concepts-permissions-schema), which
allow management of [schemas](/content/sql/ddl#sql-create-schema) and their
contained objects can be revoked from
[users](/content/security/sec_concepts#security-concepts-users) or
[roles](/content/security/sec_concepts#security-concepts-roles).

```sql title="REVOKE Schema Permission Syntax" theme={null}
REVOKE < SELECT | INSERT | UPDATE | DELETE | CREATE <object type> | ALL > [PRIVILEGES]
ON [SCHEMA] <schema reference>
FROM <user name | role name>
```

#### Parameters

<AccordionGroup>
  <Accordion title="PRIVILEGES" id="privileges-3" defaultOpen>
    Optional keyword for SQL-92 compatibility
  </Accordion>

  <Accordion title="SCHEMA" id="schema-2" defaultOpen>
    Optional keyword to avoid ambiguity between revoking a grant to a schema and a grant to a
    table/view in the user's default schema
  </Accordion>

  <Accordion title="<schema reference>" id="<schema-reference>-2" defaultOpen>
    Either the name of the schema to which access is being revoked or a wildcard expression
    signifying the schema(s) and table(s)/views(s) to which access is being revoked

    <div>
      <table class="table w-full [&_td]:min-w-[150px] [&_th]:text-left [&_td[data-numeric]]:tabular-nums">
        <thead>
          <tr>
            <th>Wildcard Form</th>
            <th>Selected Objects</th>
          </tr>
        </thead>

        <tbody>
          <tr>
            <td><code>\*</code></td>
            <td>All schemas currently in the database</td>
          </tr>

          <tr>
            <td><code>*.*</code></td>
            <td>All schemas, tables, & views currently in the database</td>
          </tr>
        </tbody>
      </table>
    </div>
  </Accordion>

  <Accordion title="<object type>" id="<object-type>-2" defaultOpen>
    For revoking `CREATE` privilege, the object type to remove permission to create in the
    given schema.

    Supported object types include:

    <div>
      <table class="table w-full [&_td]:min-w-[150px] [&_th]:text-left [&_td[data-numeric]]:tabular-nums">
        <thead>
          <tr>
            <th>Target Type</th>
            <th>Description</th>
          </tr>
        </thead>

        <tbody>
          <tr>
            <td><code>CONTEXT</code></td>
            <td>[SQL-GPT context](/content/sql/sqlgpt#sql-gpt-create-context) object</td>
          </tr>

          <tr>
            <td><code>CREDENTIAL</code></td>
            <td>[Credential](/content/sql/ddl#sql-create-credential) object</td>
          </tr>

          <tr>
            <td><code>DATA SINK</code></td>
            <td>External [data sink](/content/sql/ddl#sql-create-data-sink)</td>
          </tr>

          <tr>
            <td><code>DATA SOURCE</code></td>
            <td>External [data source](/content/sql/ddl#sql-create-data-source)</td>
          </tr>

          <tr>
            <td><code>GRAPH</code></td>
            <td>[Graph](/content/sql/graph#sql-graph-create)</td>
          </tr>

          <tr>
            <td><code>PROCEDURE</code></td>
            <td>SQL [stored procedure](/content/sql/procedure#sql-procedures)</td>
          </tr>

          <tr>
            <td><code>STREAM</code></td>
            <td>[Stream](/content/sql/ddl#sql-create-stream)</td>
          </tr>

          <tr>
            <td><code>TABLE</code></td>
            <td>[Table](/content/sql/ddl#sql-create-table) (or view)</td>
          </tr>
        </tbody>
      </table>
    </div>
  </Accordion>
</AccordionGroup>

<Info>
  The `ALL` permission corresponds to the native
  [table\_admin](/content/security/sec_concepts#security-concepts-permissions-schema) permission,
  which gives full read/write access as well as the additional permission to
  `CREATE`, `ALTER`, & `DROP` any table or view in the specified
  schema(s).
</Info>

#### Examples

To revoke `SELECT` access on all schemas from the **auditor** role:

```sql REVOKE Read on Schemas from Role Example theme={null}
REVOKE SELECT ON * FROM auditor
```

To revoke `SELECT` access on all current and future tables & views within the
**app\_schema** schema from the **app\_user** role:

```sql REVOKE Read on Schema from Role Example theme={null}
REVOKE SELECT ON app_schema FROM app_user
```

To revoke full access on each of the schemas, tables, & views in the database
individually from the **dbadmin** role:

```sql REVOKE All Permissions on All Schemas/Tables/Views from Role Example theme={null}
REVOKE ALL ON *.* FROM dbadmin
```

<a id="sql-security-priv-mgmt-table-revoke" />

### REVOKE Table Permission

[Table permissions](/content/security/sec_concepts#security-concepts-permissions-table), which can
be applied to tables and views, can be revoked from
[users](/content/security/sec_concepts#security-concepts-users) or
[roles](/content/security/sec_concepts#security-concepts-roles).

<Note>
  For revoking the ability to create *tables*, see
  [REVOKE Schema Permission](/content/sql/security#sql-security-priv-mgmt-schema-revoke).
</Note>

[Row-level security](/content/security/sec_concepts#sec-concepts-perm-table-row) can be revoked for
`SELECT` privilege only by revoking `SELECT` privilege from the entire
table.

<Info>
  Access to individual rows cannot be revoked; instead, full `SELECT`
  access should be revoked, followed by a grant of access to the appropriate
  rows.
</Info>

[Column-level security](/content/security/sec_concepts#sec-concepts-perm-table-col) can be revoked for
`SELECT` privilege by specifying a list of columns for which access will be
revoked, regardless of any security functions that may have been applied to the
column when granting access (`HASH`, `MASK`).

```sql title="REVOKE Table Permission Syntax" theme={null}
REVOKE < SELECT | INSERT | UPDATE | DELETE | ALL > [PRIVILEGES]
ON [TABLE] [<schema name>.]<table/view name> [<column list>]
FROM <user name | role name>
```

#### Parameters

<AccordionGroup>
  <Accordion title="PRIVILEGES" id="privileges-4" defaultOpen>
    Optional keyword for SQL-92 compatibility
  </Accordion>

  <Accordion title="TABLE" id="table-2" defaultOpen>
    Optional keyword for SQL-92 compatibility, and to avoid ambiguity between revoking a
    grant to a table/view in the user's default schema (when `<schema name>` is omitted)
    and a grant to a schema
  </Accordion>

  <Accordion title="<schema name>" id="<schema-name>" defaultOpen>
    The name of the schema containing the table/view to which access is being revoked; if
    omitted, the table/view will be looked for in the default schema
  </Accordion>

  <Accordion title="<table/view name>" id="<table/view-name>" defaultOpen>
    The name of the table to which access is being revoked; the wildcard `*` can be used to
    revoke access to all tables/views within the given `<schema name>` schema
  </Accordion>

  <Accordion title="<column list>" id="<column-list>-2" defaultOpen>
    Optional comma-separated list of specific table columns to which access is being revoked;
    see [Column-Level Security](/content/security/sec_concepts#sec-concepts-perm-table-col) for details
  </Accordion>
</AccordionGroup>

<Info>
  The `ALL` permission corresponds to the native
  [table\_admin](/content/security/sec_concepts#security-concepts-permissions-table) permission, which
  gives full read/write access as well as the additional permission either to
  `ALTER` and `DROP` the specified table or to `CREATE`, `ALTER`, &
  `DROP` all tables in the specified schema.
</Info>

#### Examples

For example, to revoke full access on the **network\_config** table from
**jsmith**:

```sql REVOKE All Permissions on Table from User Example theme={null}
REVOKE ALL PRIVILEGES ON TABLE example.network_config FROM jsmith
```

To revoke `SELECT` access on the **network\_config\_history** table from the
**analyst** role:

```sql REVOKE Read on Table from Role Example theme={null}
REVOKE SELECT ON example.network_config_history FROM analyst
```

To revoke full access on each of the tables & views within the **example**
schema from the **developer** role:

```sql REVOKE All Permissions on Current Tables/Views in Schema from Role Example theme={null}
REVOKE ALL ON example.* FROM developer
```

<a id="sql-security-priv-mgmt-row-revoke" />

#### Row-Level Security Examples

To revoke `SELECT` access on an **rx\_order** table for all orders placed since
the year **2002** (as was granted in the
[row-level grant example](/content/sql/security#sql-security-priv-mgmt-row-grant)), revoke all
`SELECT` access:

```sql REVOKE Row-Level Access Example theme={null}
REVOKE SELECT ON example.rx_order FROM zanalyst
```

<a id="sql-security-priv-mgmt-col-revoke" />

#### Column-Level Security Examples

To revoke `SELECT` access on the following columns of an **rx\_order** table:

* orderer's social security number

```sql REVOKE Obfuscated Column-Level Access Example theme={null}
REVOKE SELECT ON example.rx_order(ssn) FROM zanalyst
```

To revoke `SELECT` access on the following columns of an **rx\_order** table:

* masked version of the orderer's social security number (last 4 digits)
* name of the prescription ordered

```sql REVOKE Masked Column-Level Access Example theme={null}
REVOKE SELECT ON example.rx_order(ssn, rx_name) FROM rx_user
```

<a id="sql-security-priv-mgmt-cred-revoke" />

### REVOKE Credential Permission

[Permissions](/content/security/sec_concepts#security-concepts-permissions-credential) on
[credentials](/content/sql/ddl#sql-create-credential)
that have been [granted](/content/sql/security#sql-security-priv-mgmt-cred-grant)
directly to
[users](/content/security/sec_concepts#security-concepts-users) or
[roles](/content/security/sec_concepts#security-concepts-roles) can be revoked.

<Note>
  For revoking the ability to create *credentials*, see
  [REVOKE Schema Permission](/content/sql/security#sql-security-priv-mgmt-schema-revoke).
</Note>

```sql title="REVOKE Credential Permission Syntax" theme={null}
REVOKE <READ | ADMIN> ON CREDENTIAL <credential name> FROM <user name | role name>
```

#### Examples

To revoke read access on the *credential* named
**auser\_azure\_active\_dir\_creds** from the **auser** *user*:

```sql REVOKE Credential Use Permission Example theme={null}
REVOKE READ ON CREDENTIAL auser_azure_active_dir_creds FROM auser
```

To revoke administrative access on the *credential* from the **auser** *user*:

```sql REVOKE Credential Administrative Permission Example theme={null}
REVOKE ADMIN ON CREDENTIAL auser_azure_active_dir_creds FROM auser
```

<a id="sql-security-priv-mgmt-ds-revoke" />

### REVOKE Data Source Permission

[Permissions](/content/security/sec_concepts#security-concepts-permissions-datasource) on
[data sources](/content/sql/ddl#sql-create-data-source)
that have been [granted](/content/sql/security#sql-security-priv-mgmt-ds-grant)
directly to
[users](/content/security/sec_concepts#security-concepts-users) or
[roles](/content/security/sec_concepts#security-concepts-roles) can be revoked.

<Note>
  For revoking the ability to create *data sources*, see
  [REVOKE Schema Permission](/content/sql/security#sql-security-priv-mgmt-schema-revoke).
</Note>

```sql title="REVOKE Data Source Permission Syntax" theme={null}
REVOKE <CONNECT | ADMIN> ON DATA SOURCE <data source name> FROM <user name | role name>
```

#### Examples

To revoke connect access on the *data source* named **kin\_ds** from
the **auser** *user*:

```sql REVOKE Data Source Use Permission Example theme={null}
REVOKE CONNECT ON DATA SOURCE kin_ds FROM auser
```

To revoke administrative access on the *data source* named **kin\_ds\_anon** from
the **auser** *user*:

```sql REVOKE Data Source Administrative Permission Example theme={null}
REVOKE ADMIN ON DATA SOURCE kin_ds_anon FROM auser
```

<a id="sql-security-priv-mgmt-dsink-revoke" />

### REVOKE Data Sink Permission

[Permissions](/content/security/sec_concepts#security-concepts-permissions-datasink) on
[data sinks](/content/sql/ddl#sql-create-data-sink)
that have been [granted](/content/sql/security#sql-security-priv-mgmt-dsink-grant)
directly to
[users](/content/security/sec_concepts#security-concepts-users) or
[roles](/content/security/sec_concepts#security-concepts-roles) can be revoked.

<Note>
  For revoking the ability to create *data sinks*, see
  [REVOKE Schema Permission](/content/sql/security#sql-security-priv-mgmt-schema-revoke).
</Note>

```sql title="REVOKE Data Sink Permission Syntax" theme={null}
REVOKE <CONNECT | ADMIN> ON DATA SINK <data sink name> FROM <user name | role name>
```

#### Examples

To revoke connect access on the *data sink* named **kin\_dsink**
from the **auser** *user*:

```sql REVOKE Data Sink Use Permission Example theme={null}
REVOKE CONNECT ON DATA SINK kin_dsink FROM auser
```

To revoke administrative access on the *data sink* named **kin\_dsink\_http** from
the **auser** *user*:

```sql REVOKE Data Sink Administrative Permission Example theme={null}
REVOKE ADMIN ON DATA SINK kin_dsink_http FROM auser
```

<a id="sql-security-priv-mgmt-dir-revoke" />

### REVOKE Directory Permission

[Permissions](/content/security/sec_concepts#security-concepts-permissions-kifs) on
[KiFS directories](/content/sql/kifs#sql-kifs-create-dir)
that have been [granted](/content/sql/security#sql-security-priv-mgmt-dir-grant)
directly to
[users](/content/security/sec_concepts#security-concepts-users) or
[roles](/content/security/sec_concepts#security-concepts-roles) can be revoked.

<Note>
  For revoking the ability to create *directories*, see
  [REVOKE SYSTEM Permission](/content/sql/security#sql-security-priv-mgmt-sys-revoke).
</Note>

```sql title="REVOKE Directory Permission Syntax" theme={null}
REVOKE <READ | WRITE> ON DIRECTORY <directory name> FROM <user name | role name>
```

#### Examples

To revoke read access on a *directory* named **kdata** from the
**kuser** *user*:

```sql REVOKE Directory Read Permission Example theme={null}
REVOKE READ ON DIRECTORY 'kdata' FROM kuser
```

To revoke write access on a *directory* named **kdata** from the **kuser** *user*:

```sql REVOKE Directory Write Permission Example theme={null}
REVOKE WRITE ON DIRECTORY 'kdata' FROM kuser
```

<a id="sql-security-priv-mgmt-udf-revoke" />

### REVOKE Function (UDF/UDTF) Permission

Permissions relating to
[UDFs/UDTFs](/content/security/sec_concepts#security-concepts-permissions-function) and
[Python UDF function environments](/content/udf/python/writing#udf-python-func-env)
that have been [granted](/content/sql/security#sql-security-priv-mgmt-udf-grant)
directly to
[users](/content/security/sec_concepts#security-concepts-users) or
[roles](/content/security/sec_concepts#security-concepts-roles) can be revoked.

<Note>
  For revoking the ability to create *UDFs/UDTFs*, see
  [REVOKE SYSTEM Permission](/content/sql/security#sql-security-priv-mgmt-sys-revoke).
</Note>

```sql title="REVOKE FUNCTION (UDF) Permission Syntax" theme={null}
REVOKE <EXECUTE | ADMIN> ON FUNCTION < <function name> | * > FROM <user name | role name>
```

#### Examples

To revoke execute on the **udf\_sos\_py\_proc** *UDF* from **udf\_user**:

```sql REVOKE Function Execute Permission Example theme={null}
REVOKE EXECUTE ON FUNCTION UDF_SOS_PY_PROC FROM udf_user
```

To revoke administrative access on every existing & future *UDF*, as well as the
ability to manage *function environments*, from **udf\_user**:

```sql REVOKE Function Administrative Permission Example theme={null}
REVOKE ADMIN ON FUNCTION * FROM udf_user
```

<a id="sql-security-priv-mgmt-graph-revoke" />

### REVOKE Graph Permission

[Permissions](/content/security/sec_concepts#security-concepts-permissions-graph) on
[graphs](/content/sql/graph#sql-graph) that have been
[granted](/content/sql/security#sql-security-priv-mgmt-graph-grant)
directly to
[users](/content/security/sec_concepts#security-concepts-users) or
[roles](/content/security/sec_concepts#security-concepts-roles) can be revoked.

<Note>
  For revoking the ability to create *graphs*, see
  [REVOKE Schema Permission](/content/sql/security#sql-security-priv-mgmt-schema-revoke).
</Note>

```sql title="REVOKE Graph Permission Syntax" theme={null}
REVOKE <READ | WRITE | ADMIN> ON GRAPH <graph name> FROM <user name | role name>
```

#### Examples

To revoke query, match, solve, & show access on the *graph* named
**big\_cities\_graph** from **geo\_user**:

```sql REVOKE Graph Permission Example theme={null}
REVOKE READ ON GRAPH big_cities_graph FROM geo_user
```

<a id="sql-security-priv-mgmt-sqlp-revoke" />

### REVOKE Procedure Permission

Permissions relating to [SQL procedures](/content/sql/procedure#sql-procedures) can be revoked
from [users](/content/security/sec_concepts#security-concepts-users) or
[roles](/content/security/sec_concepts#security-concepts-roles).

<Note>
  For revoking the ability to create *SQL procedures*, see
  [REVOKE Schema Permission](/content/sql/security#sql-security-priv-mgmt-schema-revoke).
</Note>

```sql title="REVOKE EXECUTE PROCEDURE Permission Syntax" theme={null}
REVOKE EXECUTE PROCEDURE ON <procedure name> FROM <user name | role name>
```

#### Examples

To revoke execute on the **sqlp\_weekly** procedure from **spuser**:

```sql REVOKE EXECUTE PROCEDURE Permission Example theme={null}
REVOKE EXECUTE PROCEDURE ON example.sqlp_weekly FROM spuser
```

<a id="sql-security-priv-mgmt-gpt-revoke" />

### REVOKE SQL-GPT Context Permission

Permissions on [SQL-GPT contexts](/content/sql/sqlgpt#sql-gpt-create-context)
that have been [granted](/content/sql/security#sql-security-priv-mgmt-gpt-grant)
directly to
[users](/content/security/sec_concepts#security-concepts-users) or
[roles](/content/security/sec_concepts#security-concepts-roles) can be revoked.

<Note>
  For revoking the ability to create *SQL-GPT contexts*, see
  [REVOKE Schema Permission](/content/sql/security#sql-security-priv-mgmt-schema-revoke).
</Note>

```sql title="REVOKE SQL-GPT Context Permission Syntax" theme={null}
REVOKE <READ | ADMIN> ON CONTEXT <context name> FROM <user name | role name>
```

#### Examples

To revoke *read* access on the *SQL-GPT context* named
**example.atc\_ctx** from the **ctxuser** *user*:

```sql REVOKE SQL-GPT Context Permission Example theme={null}
REVOKE READ ON CONTEXT example.atc_ctx FROM ctxuser
```

<a id="sql-security-priv-mgmt-stream-revoke" />

### REVOKE Stream Permission

[Permissions](/content/security/sec_concepts#security-concepts-permissions-monitor) on
[streams](/content/sql/ddl#sql-create-stream)
that have been [granted](/content/sql/security#sql-security-priv-mgmt-stream-grant)
directly to
[users](/content/security/sec_concepts#security-concepts-users) or
[roles](/content/security/sec_concepts#security-concepts-roles) can be revoked.

<Note>
  For revoking the ability to create *streams*, see
  [REVOKE Schema Permission](/content/sql/security#sql-security-priv-mgmt-schema-revoke).
</Note>

```sql title="REVOKE Stream Administrative Permission Syntax" theme={null}
REVOKE ADMIN ON STREAM <stream name> FROM <user name | role name>
```

#### Examples

To revoke administrative access on the *stream* named
**kin\_stream** from the **auser** *user*:

```sql REVOKE Stream Administrative Permission Example theme={null}
REVOKE ADMIN ON STREAM example.kin_stream FROM auser
```

<a id="sql-security-show" />

### SHOW SECURITY

For any one or more (or all) [users](/content/security/sec_concepts#security-concepts-users) and
[roles](/content/security/sec_concepts#security-concepts-roles) in the system, the following can be
listed:

* [permissions](/content/security/sec_concepts#security-concepts-permissions)
* [roles](/content/security/sec_concepts#security-concepts-roles)
* [resource groups](/content/rm/concepts#rm-concepts-resource-groups)
* [default schema](/content/concepts/schemas#schema-default) (users only)

In addition, permissions, roles, & resource groups will be listed recursively
for the roles the specified users/roles have and the roles those roles have,
etc.  This allows the full set of permissions for a given user or role, both
direct & inherited, to be viewed with one command.

```sql title="SHOW SECURITY Syntax" theme={null}
SHOW SECURITY [FOR <user name | role name>,...]
```

#### Examples

To show the permissions, roles, *resource groups*, and
*default schema* for user **jsmith**:

```sql SHOW SECURITY FOR User Example theme={null}
SHOW SECURITY FOR jsmith
```

To show the permissions, roles, and *resource groups* for the **analyst** role:

```sql SHOW SECURITY FOR Role Example theme={null}
SHOW SECURITY FOR analyst
```

To show the permissions, roles, *resource groups*, and *default schema* for the
**anonymous** user and the **public** role:

```sql SHOW SECURITY FOR Multiple Users/Roles Example theme={null}
SHOW SECURITY FOR anonymous, public
```

To show all users & roles:

```sql SHOW SECURITY FOR All Users/Roles Example theme={null}
SHOW SECURITY
```

<a id="sql-security-check" />

### CHECK

[Users](/content/security/sec_concepts#security-concepts-users) (or the current user) can have
their effective permissions checked, including:

* Role assignments
* Administrative permissions
* Object-level access

A result of `YES` or `NO` will be returned, based on whether the given user
has the specified permissions or not, either directly or through a role or
administrative access.
[Row/Column-level](/content/sql/security#sql-security-priv-mgmt-row-grant) permission
information will be returned after the `YES`, if applicable.

```sql title="CHECK PERMISSION Syntax" theme={null}
CHECK <permission> [PERMISSION] [ON [<target type>] <target>]
[FOR <user>]
[IF EXISTS]
```

```sql title="CHECK ROLE Syntax" theme={null}
CHECK ROLE OF <role>
[FOR <user>]
[IF EXISTS]
```

#### Parameters

<AccordionGroup>
  <Accordion title="<permission>" id="<permission>" defaultOpen>
    Permission to verify for the given user

    Supported permissions include:

    <div>
      <table class="table w-full [&_td]:min-w-[150px] [&_th]:text-left [&_td[data-numeric]]:tabular-nums">
        <thead>
          <tr>
            <th>Permission</th>
            <th>Description</th>
          </tr>
        </thead>

        <tbody>
          <tr>
            <td><code>ADMIN</code> | <code>ALL</code></td>
            <td>Applicable to [credential](/content/sql/ddl#sql-create-credential) objects and [tables](/content/sql/ddl#sql-create-table) (or views)</td>
          </tr>

          <tr>
            <td><code>CONNECT</code></td>
            <td>Applicable to external [data sources](/content/sql/ddl#sql-create-data-source)</td>
          </tr>

          <tr>
            <td><code>DELETE</code></td>
            <td>Applicable to [tables](/content/sql/ddl#sql-create-table)</td>
          </tr>

          <tr>
            <td><code>EXECUTE</code></td>
            <td>Applicable to [User-Defined Functions](/content/sql/udf#sql-udf) (UDFs) and SQL [stored procedures](/content/sql/procedure#sql-procedures)</td>
          </tr>

          <tr>
            <td><code>INSERT</code></td>
            <td>Applicable to [tables](/content/sql/ddl#sql-create-table)</td>
          </tr>

          <tr>
            <td><code>READ</code></td>
            <td>Applicable to [credential](/content/sql/ddl#sql-create-credential) objects</td>
          </tr>

          <tr>
            <td><code>SELECT</code></td>
            <td>Applicable to [tables](/content/sql/ddl#sql-create-table) (or views)</td>
          </tr>

          <tr>
            <td><code>SYSTEM ADMIN</code></td>
            <td>[System admin](/content/sql/security#sql-perm-system-admin) permission</td>
          </tr>

          <tr>
            <td><code>SYSTEM CREATE</code></td>
            <td>[System create](/content/sql/security#sql-perm-system-mgmt) permission</td>
          </tr>

          <tr>
            <td><code>SYSTEM MONITOR</code></td>
            <td>[System monitor](/content/sql/security#sql-perm-system-mgmt) permission</td>
          </tr>

          <tr>
            <td><code>SYSTEM READ</code></td>
            <td>[System read](/content/sql/security#sql-perm-system-mgmt) permission</td>
          </tr>

          <tr>
            <td><code>SYSTEM WRITE</code></td>
            <td>[System write](/content/sql/security#sql-perm-system-mgmt) permission</td>
          </tr>

          <tr>
            <td><code>UPDATE</code></td>
            <td>Applicable to [tables](/content/sql/ddl#sql-create-table)</td>
          </tr>

          <tr>
            <td><code>USER ADMIN</code></td>
            <td>[User admin](/content/sql/security#sql-perm-user-admin) permission</td>
          </tr>
        </tbody>
      </table>
    </div>
  </Accordion>

  <Accordion title="PERMISSION" id="permission" defaultOpen>
    Optional keyword for clarity
  </Accordion>

  <Accordion title="ON" id="on-2" defaultOpen>
    Keyword for specifying the optional *ON* clause, which checks for the specified `permission`
    on the following `target` (and optional `target type`) given in this clause
  </Accordion>

  <Accordion title="<target type>" id="<target-type>" defaultOpen>
    Optional keyword for specifying the object type of the target; may be necessary to disambiguate
    same-named objects of differing types

    Supported target types include:

    <div>
      <table class="table w-full [&_td]:min-w-[150px] [&_th]:text-left [&_td[data-numeric]]:tabular-nums">
        <thead>
          <tr>
            <th>Target Type</th>
            <th>Description</th>
          </tr>
        </thead>

        <tbody>
          <tr>
            <td><code>CONTEXT</code></td>
            <td>[SQL-GPT context](/content/sql/sqlgpt#sql-gpt-create-context) object</td>
          </tr>

          <tr>
            <td><code>CREDENTIAL</code></td>
            <td>[Credential](/content/sql/ddl#sql-create-credential) object</td>
          </tr>

          <tr>
            <td><code>DATA SINK</code></td>
            <td>External [data source](/content/sql/ddl#sql-create-data-source)</td>
          </tr>

          <tr>
            <td><code>DATA SOURCE</code></td>
            <td>External [data source](/content/sql/ddl#sql-create-data-source)</td>
          </tr>

          <tr>
            <td><code>DIRECTORY</code></td>
            <td>[KiFS](/content/tools/kifs) directory</td>
          </tr>

          <tr>
            <td><code>FUNCTION</code></td>
            <td>[User-Defined Function](/content/sql/udf#sql-udf) (UDF)</td>
          </tr>

          <tr>
            <td><code>GRAPH</code></td>
            <td>[Graph](/content/sql/graph#sql-graph-create)</td>
          </tr>

          <tr>
            <td><code>PROCEDURE</code></td>
            <td>SQL [stored procedure](/content/sql/procedure#sql-procedures)</td>
          </tr>

          <tr>
            <td><code>SCHEMA</code></td>
            <td>[Schema](/content/sql/ddl#sql-create-schema)</td>
          </tr>

          <tr>
            <td><code>STREAM</code></td>
            <td>[Stream](/content/sql/ddl#sql-create-stream)</td>
          </tr>

          <tr>
            <td><code>TABLE</code></td>
            <td>[Table](/content/sql/ddl#sql-create-table) (or view)</td>
          </tr>
        </tbody>
      </table>
    </div>
  </Accordion>

  <Accordion title="<target>" id="<target>" defaultOpen>
    Name of the object to which the given user's specified permission will be checked
  </Accordion>

  <Accordion title="<role>" id="<role>" defaultOpen>
    Name of the role of which the given user's membership will be checked
  </Accordion>

  <Accordion title="FOR <user>" id="for-<user>" defaultOpen>
    Optional *FOR* clause, which checks whether the specified permission/role exists for the `user`
    given in this clause; if omitted, the current user will be checked
  </Accordion>

  <Accordion title="IF EXISTS" id="if-exists" defaultOpen>
    Optional error suppression clause, which causes the check to return `No` if any of the entities
    specified do not exist; without this clause, non-existent entities will return an error
  </Accordion>
</AccordionGroup>

<a id="sql-security-impersonation" />

## Impersonation (Execute As...)

When logged into the database as one user, SQL commands can be run as a second
user (that user can be *impersonated*).  To do this, first log in to the
database as an administrator, then switch to the second user, and finally, run
the command.  Afterwards, the original user can be reverted back to in order to
execute commands as that administrator again; alternatively, an option can be
specified to prevent switching back to the original user.

The ability to impersonate other users is available through SQL, using the
following commands:

* [EXECUTE AS](#execute-as)
* [REVERT](#revert)
* [SET USER](#set-user)

<Note>
  Only a user with administrator privilege can impersonate
  another user, and only an administrator with a Kinetica database account.
  Any users who are mapped to Kinetica as administrators via external
  authentication will need to ensure that a corresponding Kinetica
  administrator account has been created for impersonation to succeed.

  Additionally, *impersonation* is only supported via ODBC/JDBC.
</Note>

<a id="sql-security-impersonation-exec-as" />

### EXECUTE AS

During a SQL session, a user can execute subsequent commands as another user.

<Info>
  This command is only available through
  [KiSQL](/content/tools/kisql) or database clients configured with
  the [Kinetica ODBC/JDBC driver](/content/connectors/sql_guide#odbc-jdbc).
</Info>

```sql title="EXECUTE AS Syntax" theme={null}
EXEC[UTE] AS USER = '<user name>' [WITH NO REVERT]
```

The `WITH NO REVERT` option prevents the impersonated user from switching back
to the original user.  This is useful in several cases, including:

* An administrator needs to run a script as a user with specific permissions,
  but doesn't want the script to be able to revert back to administrator
  privileges during its execution.
* An application server connects to the database with its own credentials, but
  issues commands to the database on behalf of an application user.  Again,
  there is a need to prevent the application user from reverting back to the
  application server's database account and using those privileges to execute
  commands.

<a id="sql-security-impersonation-exec-as-example" />

#### Example

To demonstrate the uses of `EXECUTE AS USER`, the following commands can be
issued upon logging into the database as an administrator.

First, verify the current user is **admin**:

```sql Show Current User Example theme={null}
SELECT CURRENT_USER() AS whoami
```

```Show Current User Output theme={null}
+----------+
| whoami   |
+----------+
| admin    |
+----------+
```

Then, switch to a user **auser** and verify the session is now executing
commands as that user:

```sql Switch User Example theme={null}
EXECUTE AS USER = 'auser'
```

```sql Show Switched User theme={null}
SELECT CURRENT_USER() AS whoami
```

```Show Switched User Output theme={null}
+----------+
| whoami   |
+----------+
| auser    |
+----------+
```

Accessing a database object that **auser** has permission for results in a
successful outcome:

```sql Query Accessible Table as Switched User Example theme={null}
SELECT *
FROM example.auser_can_access
```

```Query Output theme={null}
+------+
|   id |
+------+
|    1 |
+------+
```

Accessing an object that **auser** doesn't have permission for results in an
error:

```sql Query Inaccessible Table as Switched User Example theme={null}
SELECT *
FROM example.auser_cant_access
```

```Query Output theme={null}
[GPUdb]executeSql: SqlEngine: Object 'auser_cant_access' not found within 'example' (<REF>)
```

To switch back to the original user and verify the current identity, use the
[REVERT](/content/sql/security#sql-security-impersonation-revert) command:

```sql Switch Back to Original User Example theme={null}
REVERT
```

```sql Show Switched Back User theme={null}
SELECT CURRENT_USER() AS whoami
```

```Show Switched Back User Output theme={null}
+----------+
| whoami   |
+----------+
| admin    |
+----------+
```

Now, switch to **auser** using the `WITH NO REVERT` option:

```sql Switch User without Reversion Example theme={null}
EXECUTE AS USER = 'auser' WITH NO REVERT
```

```sql Show Switched User theme={null}
SELECT CURRENT_USER() AS whoami
```

```Show Switched User Output theme={null}
+----------+
| whoami   |
+----------+
| auser    |
+----------+
```

Attempts to switch back to the administrator user will fail:

```sql Attempt to Switch Back Example theme={null}
REVERT
```

```Error Output theme={null}
Error: May not revert user after WITH NO REVERT
```

Verify the session is still executing commands as the **auser** user:

```sql Show Current User theme={null}
SELECT CURRENT_USER() AS whoami
```

```Show Current User Output theme={null}
+----------+
| whoami   |
+----------+
| auser    |
+----------+
```

<a id="sql-security-impersonation-revert" />

### REVERT

After using [EXECUTE AS](/content/sql/security#sql-security-impersonation-exec-as) or
[SET USER](/content/sql/security#sql-security-impersonation-setuser) to switch to another user, the
original user can be switched back to using the following command:

<Info>
  This command is only available through
  [KiSQL](/content/tools/kisql) or database clients configured with
  the [Kinetica ODBC/JDBC driver](/content/connectors/sql_guide#odbc-jdbc).
</Info>

```sql title="REVERT Syntax" theme={null}
REVERT
```

See the `EXECUTE AS`
[example](/content/sql/security#sql-security-impersonation-exec-as-example) for an example usage
of `REVERT`.

<a id="sql-security-impersonation-setuser" />

### SET USER

The `SET USER` (or `SETUSER`) command is simply an alias for the
[EXECUTE AS](/content/sql/security#sql-security-impersonation-exec-as) and
[REVERT](/content/sql/security#sql-security-impersonation-revert) commands.

<Info>
  This command is only available through
  [KiSQL](/content/tools/kisql) or database clients configured with
  the [Kinetica ODBC/JDBC driver](/content/connectors/sql_guide#odbc-jdbc).
</Info>

The following commands are equivalent for switching to another user:

```sql title="SET USER Syntax" theme={null}
< < SET USER <user name> > | < EXECUTE AS USER = '<user name>' > >
```

<Note>
  There is no ability to prevent reversion to the original user
  when using the `SET USER` command.  To prevent reversion, see
  [EXECUTE AS](/content/sql/security#sql-security-impersonation-exec-as).
</Note>

The following commands are equivalent for switching back to the original user:

```sql title="Revert User Syntax" theme={null}
< SET USER | REVERT >
```