DBMS privileges

All DBMS privileges are relevant system-wide. Like user management, they do not belong to one specific database or graph. For more details on the differences between graphs, databases, and the DBMS, refer to Cypher Manual → Cypher and Neo4j.

privileges grant and deny syntax dbms privileges
Figure 1. Syntax of GRANT and DENY DBMS Privileges
privileges hierarchy dbms
Figure 2. DBMS privileges hierarchy

The admin role has a number of built-in privileges. These include:

  • Create, delete, and modify databases and aliases.

  • Change configuration parameters.

  • Manage transactions.

  • Manage users and roles.

  • Manage sub-graph privileges.

  • Manage procedure security.

  • Load data.

To enable a user to perform these tasks, you can grant them the admin role, but it is also possible to make a custom role with a subset of these privileges. All privileges are also assignable using Cypher commands. For more details, see the following sections:

Using a custom role to manage DBMS privileges

In order to have an administrator role with a subset of privileges that includes all DBMS privileges, but not all database privileges, you can copy the admin role and revoke or deny the unwanted privileges. A second option is to build a custom administrator from scratch by granting the wanted privileges instead.

As an example, an administrator role can be created to only manage users and roles by using the second option:

  1. First, create the new role:

    CREATE ROLE usermanager
  2. Then grant the privilege to manage users:

    GRANT USER MANAGEMENT ON DBMS TO usermanager
  3. And to manage roles:

    GRANT ROLE MANAGEMENT ON DBMS TO usermanager

The resulting role has privileges that only allow user and role management. To list all privileges for the role usermanager as commands, run this query:

SHOW ROLE usermanager PRIVILEGES AS COMMANDS
Table 1. Result
command

"GRANT ROLE MANAGEMENT ON DBMS TO `usermanager`"

"GRANT USER MANAGEMENT ON DBMS TO `usermanager`"

Rows: 2

Note that this role does not allow all DBMS capabilities. For example, the role is missing privileges for management, creation and drop of databases as well as execution of admin procedures. To create a more powerful administrator, you can grant a different set of privileges.

In the following example, a new administrator role is created to perform almost all DBMS capabilities, excluding database management. However, the role still has some limited database capabilities, such as managing transactions:

  1. Again, start by creating a new role:

    CREATE ROLE customAdministrator
  2. Then grant the privilege for all DBMS capabilities:

    GRANT ALL DBMS PRIVILEGES ON DBMS TO customAdministrator
  3. And explicitly deny the privilege to manage databases and aliases:

    DENY DATABASE MANAGEMENT ON DBMS TO customAdministrator
  4. Next, grant the transaction management privilege:

    GRANT TRANSACTION MANAGEMENT (*) ON DATABASE * TO customAdministrator

The resulting role has privileges that include all DBMS privileges except creating, dropping, and modifying databases and aliases, as well as managing transactions. Use the following query to list all privileges for the role customAdministrator as commands:

SHOW ROLE customAdministrator PRIVILEGES AS COMMANDS
Table 2. Result
command

"DENY DATABASE MANAGEMENT ON DBMS TO `customAdministrator`"

"GRANT ALL DBMS PRIVILEGES ON DBMS TO `customAdministrator`"

"GRANT TRANSACTION MANAGEMENT (*) ON DATABASE * TO `customAdministrator`"

Rows: 3

The DBMS ROLE MANAGEMENT privileges

The DBMS privileges for role management are assignable using Cypher administrative commands. They can be granted, denied, and revoked like other privileges.

For more details about the syntax descriptions, see Cypher syntax for administration commands.

Table 3. Role management privileges command syntax
Command Description
GRANT [IMMUTABLE] CREATE ROLE
  ON DBMS
  TO role[, ...]

Enables the specified roles to create new roles.

GRANT [IMMUTABLE] RENAME ROLE
  ON DBMS
  TO role[, ...]

Enables the specified roles to change the name of roles.

GRANT [IMMUTABLE] DROP ROLE
  ON DBMS
  TO role[, ...]

Enables the specified roles to delete roles.

GRANT [IMMUTABLE] ASSIGN ROLE
  ON DBMS
  TO role[, ...]

Enables the specified roles to assign roles to users.

GRANT [IMMUTABLE] REMOVE ROLE
  ON DBMS
  TO role[, ...]

Enables the specified roles to remove roles from users.

GRANT [IMMUTABLE] SHOW ROLE
  ON DBMS
  TO role[, ...]

Enables the specified roles to list roles.

GRANT [IMMUTABLE] ROLE MANAGEMENT
  ON DBMS
  TO role[, ...]

Enables the specified roles to create, delete, assign, remove, and list roles.

The ability to add roles can be granted via the CREATE ROLE privilege. See an example:

GRANT CREATE ROLE ON DBMS TO roleAdder

The resulting role has privileges that only allow adding roles. List all privileges for the role roleAdder as commands by using the following query:

SHOW ROLE roleAdder PRIVILEGES AS COMMANDS
Table 4. Result
command

"GRANT CREATE ROLE ON DBMS TO `roleAdder`"

Rows: 1

The ability to rename roles can be granted via the RENAME ROLE privilege. See an example:

GRANT RENAME ROLE ON DBMS TO roleNameModifier

The resulting role has privileges that only allow renaming roles. List all privileges for the role roleNameModifier using the following query:

SHOW ROLE roleNameModifier PRIVILEGES AS COMMANDS
Table 5. Result
command

"GRANT RENAME ROLE ON DBMS TO `roleNameModifier`"

Rows: 1

The ability to delete roles can be granted via the DROP ROLE privilege. See an example:

GRANT DROP ROLE ON DBMS TO roleDropper

The resulting role has privileges that only allow deleting roles. List all privileges for the role roleDropper by using the following query:

SHOW ROLE roleDropper PRIVILEGES AS COMMANDS
Table 6. Result
command

"GRANT DROP ROLE ON DBMS TO `roleDropper`"

Rows: 1

The ability to assign roles to users can be granted via the ASSIGN ROLE privilege. See an example:

GRANT ASSIGN ROLE ON DBMS TO roleAssigner

The resulting role has privileges that only allow assigning/granting roles. List all privileges for the role roleAssigner as commands by using the following query:

SHOW ROLE roleAssigner PRIVILEGES AS COMMANDS
Table 7. Result
command

"GRANT ASSIGN ROLE ON DBMS TO `roleAssigner`"

Rows: 1

The ability to remove roles from users can be granted via the REMOVE ROLE privilege. See an example:

GRANT REMOVE ROLE ON DBMS TO roleRemover

The resulting role has privileges that only allow removing/revoking roles. List all privileges for the role roleRemover as commands by using the following query:

SHOW ROLE roleRemover PRIVILEGES AS COMMANDS
Table 8. Result
command

"GRANT REMOVE ROLE ON DBMS TO `roleRemover`"

Rows: 1

The ability to show roles can be granted via the SHOW ROLE privilege. A role with this privilege is allowed to execute the SHOW ROLES and SHOW POPULATED ROLES administration commands. For the SHOW ROLES WITH USERS and SHOW POPULATED ROLES WITH USERS administration commands, both this privilege and the SHOW USER privilege are required. The following query shows an example of how to grant the SHOW ROLE privilege:

In order to use SHOW ROLES WITH USERS and SHOW POPULATED ROLES WITH USERS administration commands, both the SHOW ROLE and the SHOW USER privileges are required. See an example of how to grant the SHOW ROLE privilege:

GRANT SHOW ROLE ON DBMS TO roleShower

The resulting role has privileges that only allow showing roles. List all privileges for the role roleShower as commands by using the following query:

SHOW ROLE roleShower PRIVILEGES AS COMMANDS
Table 9. Result
command

"GRANT SHOW ROLE ON DBMS TO `roleShower`"

Rows: 1

The privileges to create, rename, delete, assign, remove, and list roles can be granted via the ROLE MANAGEMENT privilege. See an example:

GRANT ROLE MANAGEMENT ON DBMS TO roleManager

The resulting role has all privileges to manage roles. List all privileges for the role roleManager as commands by using the following query:

SHOW ROLE roleManager PRIVILEGES AS COMMANDS
Table 10. Result
command

"GRANT ROLE MANAGEMENT ON DBMS TO `roleManager`"

Rows: 1

The DBMS USER MANAGEMENT privileges

The DBMS privileges for user management can be assigned using Cypher administrative commands. They can be granted, denied, and revoked like other privileges.

For more details about the syntax descriptions, see Cypher syntax for administration commands.

Table 11. User management privileges command syntax
Command Description
GRANT [IMMUTABLE] CREATE USER
  ON DBMS
  TO role[, ...]

Enables the specified roles to create new users.

GRANT [IMMUTABLE] RENAME USER
  ON DBMS
  TO role[, ...]

Enables the specified roles to change the name of users.

GRANT [IMMUTABLE] ALTER USER
  ON DBMS
  TO role[, ...]

Enables the specified roles to modify users.

GRANT [IMMUTABLE] SET PASSWORD[S]
  ON DBMS
  TO role[, ...]

Enables the specified roles to modify users' passwords and whether those passwords must be changed upon first login.

GRANT [IMMUTABLE] SET AUTH
  ON DBMS
  TO role[, ...]

Introduced in 5.24 Enables the specified roles to SET or REMOVE users' auth providers.

GRANT [IMMUTABLE] SET USER HOME DATABASE
  ON DBMS
  TO role[, ...]

Enables the specified roles to modify users' home database.

GRANT [IMMUTABLE] SET USER STATUS
  ON DBMS
  TO role[, ...]

Enables the specified roles to modify the account status of users.

GRANT [IMMUTABLE] DROP USER
  ON DBMS
  TO role[, ...]

Enables the specified roles to delete users.

GRANT [IMMUTABLE] SHOW USER
  ON DBMS
  TO role[, ...]

Enables the specified roles to list users.

GRANT [IMMUTABLE] USER MANAGEMENT
  ON DBMS
  TO role[, ...]

Enables the specified roles to create, delete, modify, and list users.

The ability to add users can be granted via the CREATE USER privilege. See an example:

GRANT CREATE USER ON DBMS TO userAdder

The resulting role has privileges that only allow adding users. List all privileges for the role userAdder as commands by using this query:

SHOW ROLE userAdder PRIVILEGES AS COMMANDS
Table 12. Result
command

"GRANT CREATE USER ON DBMS TO `userAdder`"

Rows: 1

The ability to rename users can be granted via the RENAME USER privilege. The following query shows an example of this:

GRANT RENAME USER ON DBMS TO userNameModifier

The resulting role has privileges that only allow renaming users:

SHOW ROLE userNameModifier PRIVILEGES AS COMMANDS

Lists all privileges for role userNameModifier:

Table 13. Result
command

"GRANT RENAME USER ON DBMS TO `userNameModifier`"

Rows: 1

The ability to modify users can be granted via the ALTER USER privilege. See an example:

GRANT ALTER USER ON DBMS TO userModifier

The resulting role has privileges that only allow modifying users. List all privileges for the role userModifier as commands by using the following query:

SHOW ROLE userModifier PRIVILEGES AS COMMANDS
Table 14. Result
command

"GRANT ALTER USER ON DBMS TO `userModifier`"

Rows: 1

A user that is granted the ALTER USER privilege is allowed to run the ALTER USER administration command with one or several of the SET PASSWORD, SET PASSWORD CHANGE [NOT] REQUIRED, SET AUTH, REMOVE AUTH and SET STATUS parts:

ALTER USER jake SET PASSWORD 'verysecret' SET STATUS SUSPENDED

The ability to modify users' passwords and whether those passwords must be changed upon first login can be granted via the SET PASSWORDS privilege. See an example:

GRANT SET PASSWORDS ON DBMS TO passwordModifier

The resulting role has privileges that only allow modifying users' passwords and whether those passwords must be changed upon first login. List all privileges for the role passwordModifier as commands by using the following query:

SHOW ROLE passwordModifier PRIVILEGES AS COMMANDS
Table 15. Result
command

"GRANT SET PASSWORD ON DBMS TO `passwordModifier`"

Rows: 1

A user that is granted the SET PASSWORDS privilege is allowed to run the ALTER USER administration command with one or both of the SET PASSWORD and SET PASSWORD CHANGE [NOT] REQUIRED parts:

ALTER USER jake SET PASSWORD 'abcd5678' CHANGE NOT REQUIRED

Introduced in 5.24 A user that is granted the SET AUTH privilege is allowed to run the ALTER USER administration command with one or both of the SET AUTH and REMOVE AUTH parts:

ALTER USER jake REMOVE AUTH 'native SET AUTH 'oidc-okta' { SET id 'jakesUniqueOktaUserId' }

The ability to modify the account status of users can be granted via the SET USER STATUS privilege. See an example:

GRANT SET USER STATUS ON DBMS TO statusModifier

The resulting role has privileges that only allow modifying the account status of users. List all privileges for the role statusModifier as commands by using the following query:

SHOW ROLE statusModifier PRIVILEGES AS COMMANDS
Table 16. Result
command

"GRANT SET USER STATUS ON DBMS TO `statusModifier`"

Rows: 1

A user that is granted the SET USER STATUS privilege is allowed to run the ALTER USER administration command with only the SET STATUS part:

ALTER USER jake SET STATUS ACTIVE

In order to be able to modify the home database of users, grant the SET USER HOME DATABASE privilege. See an example:

GRANT SET USER HOME DATABASE ON DBMS TO statusModifier

The resulting role has privileges that only allow modifying the home database of users. List all privileges for the role statusModifier as commands by using the following query:

SHOW ROLE statusModifier PRIVILEGES AS COMMANDS
Table 17. Result
command

"GRANT SET USER HOME DATABASE ON DBMS TO `statusModifier`"

"GRANT SET USER STATUS ON DBMS TO `statusModifier`"

Rows: 2

A user that is granted the SET USER HOME DATABASE privilege is allowed to run the ALTER USER administration command with only the SET HOME DATABASE or REMOVE HOME DATABASE part:

ALTER USER jake SET HOME DATABASE otherDb
ALTER USER jake REMOVE HOME DATABASE

Note that the combination of the SET PASSWORDS, SET AUTH, SET USER STATUS, and the SET USER HOME DATABASE privilege actions is equivalent to the ALTER USER privilege action.

The ability to delete users can be granted via the DROP USER privilege. See an example:

GRANT DROP USER ON DBMS TO userDropper

The resulting role has privileges that only allow deleting users. List all privileges for the role userDropper as commands by using the following query:

SHOW ROLE userDropper PRIVILEGES AS COMMANDS
Table 18. Result
command

"GRANT DROP USER ON DBMS TO `userDropper`"

Rows: 1

The ability to show users can be granted via the SHOW USER privilege. See an example:

GRANT SHOW USER ON DBMS TO userShower

The resulting role has privileges that only allow showing users. List all privileges for the role userShower as commands by using the following query:

SHOW ROLE userShower PRIVILEGES AS COMMANDS
Table 19. Result
command

"GRANT SHOW USER ON DBMS TO `userShower`"

Rows: 1

The privileges to create, rename, modify, delete, and list users can be granted via the USER MANAGEMENT privilege. See an example:

GRANT USER MANAGEMENT ON DBMS TO userManager

The resulting role has all privileges to manage users. List all privileges for the role userManager as commands by using the following query:

SHOW ROLE userManager PRIVILEGES AS COMMANDS
Table 20. Result
command

"GRANT SHOW USER ON DBMS TO `userManager`"

Rows: 1

The DBMS IMPERSONATE privileges

The DBMS privileges for impersonation can be assigned through Cypher administrative commands. They can be granted, denied, and revoked like other privileges.

Impersonation is the ability of a user to assume another user’s roles (and therefore privileges), with the restriction of not being able to execute updating admin commands as the impersonated user (i.e. they would still be able to use SHOW commands).

The ability to impersonate users can be granted via the IMPERSONATE privilege.

For more details about the syntax descriptions, see Cypher syntax for administration commands.

Table 21. Impersonation privileges command syntax
Command Description
GRANT [IMMUTABLE] IMPERSONATE [(*)]
    ON DBMS
    TO role[, ...]

Enables the specified roles to impersonate any user.

GRANT [IMMUTABLE] IMPERSONATE (user[, ...])
    ON DBMS
    TO role[, ...]

Enables the specified roles to impersonate the specified users.

The following query shows an example of this. Note that userImpersonator must be an existing role in order to make this query work:

Query
GRANT IMPERSONATE (*) ON DBMS TO userImpersonator

The resulting role has privileges that allow impersonating all users:

Query
SHOW ROLE userImpersonator PRIVILEGES AS COMMANDS
Table 22. Result
command

"GRANT IMPERSONATE (*) ON DBMS TO `userImpersonator`"

Rows: 1

It is also possible to deny and revoke that privilege. See an example which shows of how the userImpersonator user would be able to impersonate all users, except alice:

Query
DENY IMPERSONATE (alice) ON DBMS TO userImpersonator

To grant (or revoke) the permissions to impersonate a specific user or a subset of users, you can first list them with this query:

Query
GRANT IMPERSONATE (alice, bob) ON DBMS TO userImpersonator

The DBMS DATABASE MANAGEMENT privileges

The DBMS privileges for database management can be assigned by using Cypher administrative commands. They can be granted, denied and revoked like other privileges.

For more details about the syntax descriptions, see Cypher syntax for administration commands.

Table 23. Database management privileges command syntax
Command Description
GRANT [IMMUTABLE] CREATE DATABASE
  ON DBMS
  TO role[, ...]

Enables the specified roles to create new standard databases and aliases.

GRANT [IMMUTABLE] DROP DATABASE
  ON DBMS
  TO role[, ...]

Enables the specified roles to delete standard databases and aliases.

GRANT [IMMUTABLE] ALTER DATABASE
  ON DBMS
  TO role[, ...]

Enables the specified roles to modify standard databases and aliases.

GRANT [IMMUTABLE] SET DATABASE ACCESS
  ON DBMS
  TO role[, ...]

Enables the specified roles to modify access to standard databases.

GRANT CREATE COMPOSITE DATABASE
  ON DBMS
  TO role[, ...]

Enables the specified roles to create new composite databases.

GRANT DROP COMPOSITE DATABASE
  ON DBMS
  TO role[, ...]

Enables the specified roles to delete composite databases.

GRANT COMPOSITE DATABASE MANAGEMENT
  ON DBMS
  TO role[, ...]

Enables the specified roles to create and delete composite databases.

GRANT [IMMUTABLE] DATABASE MANAGEMENT
  ON DBMS
  TO role[, ...]

Enables the specified roles to create, delete, and modify databases and aliases.

The ability to create standard databases and aliases can be granted via the CREATE DATABASE privilege. See an example:

GRANT CREATE DATABASE ON DBMS TO databaseAdder

The resulting role has privileges that only allow creating standard databases and aliases. List all privileges for the role databaseAdder as commands by using the following query:

SHOW ROLE databaseAdder PRIVILEGES AS COMMANDS
Table 24. Result
command

"GRANT CREATE DATABASE ON DBMS TO `databaseAdder`"

Rows: 1

The ability to create composite databases can be granted via the CREATE COMPOSITE DATABASE privilege. See an example:

GRANT CREATE COMPOSITE DATABASE ON DBMS TO compositeDatabaseAdder

The resulting role has privileges that only allow creating composite databases. List all privileges for the role compositeDatabaseAdder as commands by using the following query:

SHOW ROLE compositeDatabaseAdder PRIVILEGES AS COMMANDS
Table 25. Result
command

"GRANT CREATE COMPOSITE DATABASE ON DBMS TO `compositeDatabaseAdder`"

Rows: 1

The ability to delete standard databases and aliases can be granted via the DROP DATABASE privilege. See an example:

GRANT DROP DATABASE ON DBMS TO databaseDropper

The resulting role has privileges that only allow deleting standard databases and aliases. List all privileges for the role databaseDropper as commands by using the following query:

SHOW ROLE databaseDropper PRIVILEGES AS COMMANDS
Table 26. Result
command

"GRANT DROP DATABASE ON DBMS TO `databaseDropper`"

Rows: 1

The ability to delete composite databases can be granted via the DROP COMPOSITE DATABASE privilege. See an example:

GRANT DROP COMPOSITE DATABASE ON DBMS TO compositeDatabaseDropper

The resulting role has privileges that only allow deleting composite databases. List all privileges for the role compositeDatabaseDropper as commands by using the following query:

SHOW ROLE compositeDatabaseDropper PRIVILEGES AS COMMANDS
Table 27. Result
command

"GRANT DROP COMPOSITE DATABASE ON DBMS TO `compositeDatabaseDropper`"

Rows: 1

The ability to modify standard databases and aliases can be granted via the ALTER DATABASE privilege. See an example:

GRANT ALTER DATABASE ON DBMS TO databaseModifier

The resulting role has privileges that only allow modifying standard databases and aliases. List all privileges for the role databaseModifier as commands by using the following query:

SHOW ROLE databaseModifier PRIVILEGES AS COMMANDS
Table 28. Result
command

"GRANT ALTER DATABASE ON DBMS TO `databaseModifier`"

Rows: 1

The ability to modify access to standard databases can be granted via the SET DATABASE ACCESS privilege. See an example:

GRANT SET DATABASE ACCESS ON DBMS TO accessModifier

The resulting role has privileges that only allow modifying access to standard databases. List all privileges for the role accessModifier as commands by using the following query:

SHOW ROLE accessModifier PRIVILEGES AS COMMANDS
Table 29. Result
command

"GRANT SET DATABASE ACCESS ON DBMS TO `accessModifier`"

Rows: 1

The ability to create and delete composite databases can be granted via the COMPOSITE DATABASE MANAGEMENT privilege. See an example:

GRANT COMPOSITE DATABASE MANAGEMENT ON DBMS TO compositeDatabaseManager

The resulting role has all privileges to manage composite databases. List all privileges for the role compositeDatabaseManager as commands by using the following query:

SHOW ROLE compositeDatabaseManager PRIVILEGES AS COMMANDS
Table 30. Result
command

"GRANT COMPOSITE DATABASE MANAGEMENT ON DBMS TO `compositeDatabaseManager`"

Rows: 1

The ability to create, delete, and modify databases and aliases can be granted via the DATABASE MANAGEMENT privilege. See an example:

GRANT DATABASE MANAGEMENT ON DBMS TO databaseManager

The resulting role has all privileges to manage standard and composite databases as well as aliases. List all privileges for the role databaseManager as commands by using the following query:

SHOW ROLE databaseManager PRIVILEGES AS COMMANDS
Table 31. Result
command

"GRANT DATABASE MANAGEMENT ON DBMS TO `databaseManager`"

Rows: 1

The DBMS ALIAS MANAGEMENT privileges

The DBMS privileges for alias management can be assigned by using Cypher administrative commands and can be applied to both local and remote aliases. They can be granted, denied and revoked like other privileges. It is also possible to manage aliases with database management commands.

For more details about the syntax descriptions, see Cypher syntax for administration commands.

Table 32. Alias management privileges command syntax
Command Description
GRANT [IMMUTABLE] CREATE ALIAS
ON DBMS
TO role[, ...]

Enables the specified roles to create new aliases.

GRANT [IMMUTABLE] DROP ALIAS
ON DBMS
TO role[, ...]

Enables the specified roles to delete aliases.

GRANT [IMMUTABLE] ALTER ALIAS
ON DBMS
TO role[, ...]

Enables the specified roles to modify aliases.

GRANT [IMMUTABLE] SHOW ALIAS
ON DBMS
TO role[, ...]

Enables the specified roles to list aliases.

GRANT [IMMUTABLE] ALIAS MANAGEMENT
ON DBMS
TO role[, ...]

Enables the specified roles to list, create, delete, and modify aliases.

The ability to create aliases can be granted via the CREATE ALIAS privilege. See an example:

GRANT CREATE ALIAS ON DBMS TO aliasAdder

The resulting role has privileges that only allow creating aliases. List all privileges for the role aliasAdder as commands by using the following query:

SHOW ROLE aliasAdder PRIVILEGES AS COMMANDS
Table 33. Result
command

"GRANT CREATE ALIAS ON DBMS TO `aliasAdder`"

Rows: 1

The ability to delete aliases can be granted via the DROP ALIAS privilege. See an example:

GRANT DROP ALIAS ON DBMS TO aliasDropper

The resulting role has privileges that only allow deleting aliases. See all privileges for the role aliasDropper as commands by using the following query:

SHOW ROLE aliasDropper PRIVILEGES AS COMMANDS
Table 34. Result
command

"GRANT DROP ALIAS ON DBMS TO `aliasDropper`"

Rows: 1

The ability to modify aliases can be granted via the ALTER ALIAS privilege. See an example:

GRANT ALTER ALIAS ON DBMS TO aliasModifier

The resulting role has privileges that only allow modifying aliases. List all privileges for the role aliasModifier as commands by using the following query:

SHOW ROLE aliasModifier PRIVILEGES AS COMMANDS
Table 35. Result
command

"GRANT ALTER ALIAS ON DBMS TO `aliasModifier`"

Rows: 1

The ability to list aliases can be granted via the SHOW ALIAS privilege. See an example:

GRANT SHOW ALIAS ON DBMS TO aliasLister

The resulting role has privileges that only allow modifying aliases. List all privileges for the role aliasLister as commands by using the following query:

SHOW ROLE aliasLister PRIVILEGES AS COMMANDS
Table 36. Result
command

"GRANT SHOW ALIAS ON DBMS TO `aliasLister`"

Rows: 1

The privileges to list, create, delete, and modify aliases can be granted via the ALIAS MANAGEMENT privilege. See an example:

GRANT ALIAS MANAGEMENT ON DBMS TO aliasManager

The resulting role has all privileges to manage aliases. List all privileges for the role aliasManager as commands by using the following query:

SHOW ROLE aliasManager PRIVILEGES AS COMMANDS
Table 37. Result
command

"GRANT ALIAS MANAGEMENT ON DBMS TO `aliasManager`"

Rows: 1

The DBMS SERVER MANAGEMENT privileges

The DBMS privileges for server management can be assigned using Cypher administrative commands. They can be granted, denied, and revoked like other privileges.

For more details about the syntax descriptions, see Cypher syntax for administration commands.

Table 38. Server management privileges command syntax
Command Description
GRANT [IMMUTABLE] SERVER MANAGEMENT
  ON DBMS
  TO role[, ...]

Enables the specified roles to show, enable, rename, alter, reallocate, deallocate, and drop servers.

GRANT [IMMUTABLE] SHOW SERVERS
  ON DBMS
  TO role[, ...]

Enables the specified roles to show servers.

The DBMS PRIVILEGE MANAGEMENT privileges

The DBMS privileges for privilege management can be assigned by using Cypher administrative commands. They can be granted, denied and revoked like other privileges.

For more details about the syntax descriptions, see Cypher syntax for administration commands.

Table 39. Privilege management privileges command syntax
Command Description
GRANT [IMMUTABLE] SHOW PRIVILEGE
  ON DBMS
  TO role[, ...]

Enables the specified roles to list privileges.

GRANT [IMMUTABLE] ASSIGN PRIVILEGE
  ON DBMS
  TO role[, ...]

Enables the specified roles to assign privileges using the GRANT and DENY commands.

GRANT [IMMUTABLE] REMOVE PRIVILEGE
  ON DBMS
  TO role[, ...]

Enables the specified roles to remove privileges using the REVOKE command.

GRANT [IMMUTABLE] PRIVILEGE MANAGEMENT
  ON DBMS
  TO role[, ...]

Enables the specified roles to list, assign, and remove privileges.

The ability to list privileges can be granted via the SHOW PRIVILEGE privilege.

A user with this privilege is allowed to execute the SHOW PRIVILEGES and SHOW ROLE roleName PRIVILEGES administration commands. To execute the SHOW USER username PRIVILEGES administration command, both this privilege and the SHOW USER privilege are required. The following query shows an example of how to grant the SHOW PRIVILEGE privilege:

GRANT SHOW PRIVILEGE ON DBMS TO privilegeShower

The resulting role has privileges that only allow showing privileges. List all privileges for the role privilegeShower as commands by using the following query:

SHOW ROLE privilegeShower PRIVILEGES AS COMMANDS
Table 40. Result
command

"GRANT SHOW PRIVILEGE ON DBMS TO `privilegeShower`"

Rows: 1

Note that no specific privileges are required for showing the current user’s privileges through the SHOW USER username PRIVILEGES or SHOW USER PRIVILEGES commands.

In addition, note that if a non-native auth provider like LDAP is in use, SHOW USER PRIVILEGES will only work with a limited capacity by making it only possible for a user to show their own privileges. Other users' privileges cannot be listed when using a non-native auth provider.

The ability to assign privileges to roles can be granted via the ASSIGN PRIVILEGE privilege. A user with this privilege is allowed to execute GRANT and DENY administration commands. See an example of how to grant this privilege:

GRANT ASSIGN PRIVILEGE ON DBMS TO privilegeAssigner

The resulting role has privileges that only allow assigning privileges. List all privileges for the role privilegeAssigner as commands by using the following query:

SHOW ROLE privilegeAssigner PRIVILEGES AS COMMANDS
Table 41. Result
command

"GRANT ASSIGN PRIVILEGE ON DBMS TO `privilegeAssigner`"

Rows: 1

The ability to remove privileges from roles can be granted via the REMOVE PRIVILEGE privilege.

A user with this privilege is allowed to execute REVOKE administration commands. See an example of how to grant this privilege:

GRANT REMOVE PRIVILEGE ON DBMS TO privilegeRemover

The resulting role has privileges that only allow removing privileges. List all privileges for the role privilegeRemover as commands by using the following query:

SHOW ROLE privilegeRemover PRIVILEGES AS COMMANDS
Table 42. Result
command

"GRANT REMOVE PRIVILEGE ON DBMS TO `privilegeRemover`"

Rows: 1

The privileges to list, assign, and remove privileges can be granted via the PRIVILEGE MANAGEMENT privilege. See an example:

GRANT PRIVILEGE MANAGEMENT ON DBMS TO privilegeManager

The resulting role has all privileges to manage privileges. List all privileges for the role privilegeManager as commands by using the following query:

SHOW ROLE privilegeManager PRIVILEGES AS COMMANDS
Table 43. Result
command

"GRANT PRIVILEGE MANAGEMENT ON DBMS TO `privilegeManager`"

Rows: 1

The DBMS EXECUTE privileges

The DBMS privileges for procedure and user-defined function execution can be assigned by using Cypher administrative commands. They can be granted, denied and revoked like other privileges.

For more details about the syntax descriptions, see Cypher syntax for administration commands.

Table 44. Execute privileges command syntax
Command Description
GRANT [IMMUTABLE] EXECUTE PROCEDURE[S] name-globbing[, ...]
  ON DBMS
  TO role[, ...]

Enables the specified roles to execute the given procedures.

GRANT [IMMUTABLE] EXECUTE BOOSTED PROCEDURE[S] name-globbing[, ...]
  ON DBMS
  TO role[, ...]

Enables the specified roles to use elevated privileges when executing the given procedures.

GRANT [IMMUTABLE] EXECUTE ADMIN[ISTRATOR] PROCEDURES
  ON DBMS
  TO role[, ...]

Enables the specified roles to execute procedures annotated with @Admin. The procedures are executed with elevated privileges.

GRANT [IMMUTABLE] EXECUTE [USER [DEFINED]] FUNCTION[S] name-globbing[, ...]
  ON DBMS
  TO role[, ...]

Enables the specified roles to execute the given user-defined functions.

GRANT [IMMUTABLE] EXECUTE BOOSTED [USER [DEFINED]] FUNCTION[S] name-globbing[, ...]
  ON DBMS
  TO role[, ...]

Enables the specified roles to use elevated privileges when executing the given user-defined functions.

The EXECUTE PROCEDURE privilege

The ability to execute a procedure can be granted via the EXECUTE PROCEDURE privilege. A role with this privilege is allowed to execute the procedures matched by the name-globbing. The following query shows an example of how to grant this privilege:

GRANT EXECUTE PROCEDURE db.schema.* ON DBMS TO procedureExecutor

Users with the role procedureExecutor can then run any procedure in the db.schema namespace. The procedure is run using the user’s own privileges.

The resulting role has privileges that only allow executing procedures in the db.schema namespace. List all privileges for the role procedureExecutor as commands by using the following query:

SHOW ROLE procedureExecutor PRIVILEGES AS COMMANDS
Table 45. Result
command

"GRANT EXECUTE PROCEDURE db.schema.* ON DBMS TO `procedureExecutor`"

Rows: 1

In order to allow the execution of all but only a few procedures, you can grant EXECUTE PROCEDURES * and deny the unwanted procedures. For example, the following queries allow the execution of all procedures, except those starting with dbms.cluster:

GRANT EXECUTE PROCEDURE * ON DBMS TO deniedProcedureExecutor
DENY EXECUTE PROCEDURE dbms.cluster* ON DBMS TO deniedProcedureExecutor

The resulting role has privileges that only allow executing all procedures except those starting with dbms.cluster. List all privileges for the role deniedProcedureExecutor as commands by using the following query:

SHOW ROLE deniedProcedureExecutor PRIVILEGES AS COMMANDS
Table 46. Result
command

"DENY EXECUTE PROCEDURE dbms.cluster* ON DBMS TO `deniedProcedureExecutor`"

"GRANT EXECUTE PROCEDURE * ON DBMS TO `deniedProcedureExecutor`"

Rows: 2

The dbms.cluster.checkConnectivity, dbms.cluster.cordonServer, dbms.cluster.protocols, dbms.cluster.readReplicaToggle, dbms.cluster.routing.getRoutingTable, dbms.cluster.secondaryReplicationDisable, dbms.cluster.setAutomaticallyEnableFreeServers, and dbms.cluster.uncordonServer procedures are blocked, as well as any others starting with dbms.cluster.

The EXECUTE BOOSTED PROCEDURE privilege

The ability to use elevated privileges when executing a procedure can be granted via the EXECUTE BOOSTED PROCEDURE privilege. A user with this privilege will not be restricted to their other privileges when executing the procedures matched by the name-globbing. The EXECUTE BOOSTED PROCEDURE privilege only affects the elevation, and not the execution of the procedure. Therefore, it is needed to grant EXECUTE PROCEDURE privilege for the procedures as well.

Since Neo4j 5.0, both EXECUTE PROCEDURE and EXECUTE BOOSTED PROCEDURE are needed to execute a procedure with elevated privileges. This differs from Neo4j 4.x, when only the EXECUTE BOOSTED PROCEDURE is required.

GRANT EXECUTE PROCEDURE * ON DBMS TO boostedProcedureExecutor;
GRANT EXECUTE BOOSTED PROCEDURE db.labels, db.relationshipTypes ON DBMS TO boostedProcedureExecutor

Users with the role boostedProcedureExecutor can thus run the db.labels and the db.relationshipTypes procedures with full privileges, seeing everything in the graph and not just the labels and types that the user has TRAVERSE privilege on. Without the EXECUTE PROCEDURE, no procedures could be executed at all.

The resulting role has privileges that allow executing the procedures db.labels and db.relationshipTypes with elevated privileges, and all other procedures with the user’s own privileges:

SHOW ROLE boostedProcedureExecutor PRIVILEGES AS COMMANDS
Table 47. Result
command

"GRANT EXECUTE PROCEDURE * ON DBMS TO `boostedProcedureExecutor`"

"GRANT EXECUTE BOOSTED PROCEDURE db.labels ON DBMS TO `boostedProcedureExecutor`"

"GRANT EXECUTE BOOSTED PROCEDURE db.relationshipTypes ON DBMS TO `boostedProcedureExecutor`"

Rows: 3

As with grant, denying EXECUTE BOOSTED PROCEDURE on its own only affects the elevation and not the execution of the procedure. This can be seen in the following examples:

Example 1. Grant EXECUTE PROCEDURE and deny EXECUTE BOOSTED PROCEDURE
GRANT EXECUTE PROCEDURE * ON DBMS TO deniedBoostedProcedureExecutor1
DENY EXECUTE BOOSTED PROCEDURE db.labels ON DBMS TO deniedBoostedProcedureExecutor1

The resulting role has privileges that allow the execution of all procedures using the user’s own privileges. It also prevents the db.labels procedure from being elevated. Still, the denied EXECUTE BOOSTED PROCEDURE does not block execution of db.labels.

To list all privileges for role deniedBoostedProcedureExecutor1 as commands, use the following query:

SHOW ROLE deniedBoostedProcedureExecutor1 PRIVILEGES AS COMMANDS
Table 48. Result
command

"DENY EXECUTE BOOSTED PROCEDURE db.labels ON DBMS TO `deniedBoostedProcedureExecutor1`"

"GRANT EXECUTE PROCEDURE * ON DBMS TO `deniedBoostedProcedureExecutor1`"

Rows: 2

Example 2. Grant EXECUTE BOOSTED PROCEDURE and deny EXECUTE PROCEDURE
GRANT EXECUTE BOOSTED PROCEDURE * ON DBMS TO deniedBoostedProcedureExecutor2
DENY EXECUTE PROCEDURE db.labels ON DBMS TO deniedBoostedProcedureExecutor2

The resulting role has privileges that allow elevating the privileges for all procedures, but cannot execute any due to missing or denied EXECUTE PROCEDURE privileges. List all privileges for the role deniedBoostedProcedureExecutor2 as commands by using the following query:

SHOW ROLE deniedBoostedProcedureExecutor2 PRIVILEGES AS COMMANDS
Table 49. Result
command

"DENY EXECUTE PROCEDURE db.labels ON DBMS TO `deniedBoostedProcedureExecutor2`"

"GRANT EXECUTE BOOSTED PROCEDURE * ON DBMS TO `deniedBoostedProcedureExecutor2`"

Rows: 2

Example 3. Grant EXECUTE BOOSTED PROCEDURE and deny EXECUTE BOOSTED PROCEDURE
GRANT EXECUTE BOOSTED PROCEDURE * ON DBMS TO deniedBoostedProcedureExecutor3
DENY EXECUTE BOOSTED PROCEDURE db.labels ON DBMS TO deniedBoostedProcedureExecutor3

The resulting role has privileges that allow elevating the privileges for all procedures except db.labels, however no procedures can be executed due to missing EXECUTE PROCEDURE privilege. List all privileges for the role deniedBoostedProcedureExecutor3 as commands by using the following query:

SHOW ROLE deniedBoostedProcedureExecutor3 PRIVILEGES AS COMMANDS
Table 50. Result
command

"DENY EXECUTE BOOSTED PROCEDURE db.labels ON DBMS TO `deniedBoostedProcedureExecutor3`"

"GRANT EXECUTE BOOSTED PROCEDURE * ON DBMS TO `deniedBoostedProcedureExecutor3`"

Rows: 2

Example 4. How would the privileges from examples 1 to 3 affect the output of a procedure?

Assume there is a procedure called myProc.

This procedure gives the result A and B for a user with EXECUTE PROCEDURE privilege and A, B and C for a user with EXECUTE BOOSTED PROCEDURE privilege.

Now, adapt the privileges from examples 1 to 3 to be applied to this procedure and show what is returned. With the privileges from example 1, granted EXECUTE PROCEDURE * and denied EXECUTE BOOSTED PROCEDURE myProc, the myProc procedure returns the result A and B.

With the privileges from example 2, granted EXECUTE BOOSTED PROCEDURE * and denied EXECUTE PROCEDURE myProc, execution of the myProc procedure is not allowed.

With the privileges from example 3, granted EXECUTE BOOSTED PROCEDURE * and denied EXECUTE BOOSTED PROCEDURE myProc, execution of the myProc procedure is not allowed.

For comparison, when granted:

  • EXECUTE PROCEDURE myProc: the myProc procedure returns the result A and B.

  • EXECUTE BOOSTED PROCEDURE myProc: execution of the myProc procedure is not allowed.

  • EXECUTE PROCEDURE myProc and EXECUTE BOOSTED PROCEDURE myProc: the myProc procedure returns the result A, B, and C.

The EXECUTE ADMIN PROCEDURE privilege

The ability to execute admin procedures (annotated with @Admin) can be granted via the EXECUTE ADMIN PROCEDURES privilege. This privilege is equivalent with granting the EXECUTE PROCEDURE and EXECUTE BOOSTED PROCEDURE privileges on each of the admin procedures. Any newly added admin procedure is automatically included in this privilege. The following query shows an example of how to grant this privilege:

GRANT EXECUTE ADMIN PROCEDURES ON DBMS TO adminProcedureExecutor

Users with the role adminProcedureExecutor can then run any admin procedure with elevated privileges. The resulting role has privileges that allow the execution of all admin procedures.

List all privileges for the role adminProcedureExecutor as commands by using the following query:

SHOW ROLE adminProcedureExecutor PRIVILEGES AS COMMANDS
Table 51. Result
command

"GRANT EXECUTE ADMIN PROCEDURES ON DBMS TO `adminProcedureExecutor`"

Rows: 1

In order to compare this with the EXECUTE PROCEDURE and EXECUTE BOOSTED PROCEDURE privileges, revisit the myProc procedure, but this time as an admin procedure, which will give the result A, B and C when allowed to execute.

By starting with a user only granted the EXECUTE PROCEDURE myProc or the EXECUTE BOOSTED PROCEDURE myProc privilege, execution of the myProc procedure is not allowed.

However, for a user granted the EXECUTE ADMIN PROCEDURES or both EXECUTE PROCEDURE myProc and EXECUTE BOOSTED PROCEDURE myProc, the myProc procedure returns the result A, B and C.

Any denied EXECUTE privilege results in the procedure not being allowed to be executed. In this case, it does not matter whether EXECUTE PROCEDURE, EXECUTE BOOSTED PROCEDURE or EXECUTE ADMIN PROCEDURES is being denied.

The EXECUTE USER DEFINED FUNCTION privilege

The ability to execute a user-defined function (UDF) can be granted via the EXECUTE USER DEFINED FUNCTION privilege. A role with this privilege is allowed to execute the UDFs matched by the name-globbing.

The EXECUTE USER DEFINED FUNCTION privilege does not apply to built-in functions, which are always executable.

Example 5. Execute user-defined function

The following query shows an example of how to grant this privilege:

GRANT EXECUTE USER DEFINED FUNCTION apoc.coll.* ON DBMS TO functionExecutor

Or in short form:

GRANT EXECUTE FUNCTION apoc.coll.* ON DBMS TO functionExecutor

Users with the role functionExecutor can thus run any UDF in the apoc.coll namespace. The function here is run using the user’s own privileges.

The resulting role has privileges that only allow executing UDFs in the apoc.coll namespace. List all privileges for the role functionExecutor as commands by using the following query:

SHOW ROLE functionExecutor PRIVILEGES AS COMMANDS
Table 52. Result
command

"GRANT EXECUTE FUNCTION apoc.coll.* ON DBMS TO `functionExecutor`"

Rows: 1

To allow the execution of all but a few UDFs, you can grant EXECUTE USER DEFINED FUNCTIONS * and deny the unwanted functions.

Example 6. Execute user-defined functions

The following queries allow the execution of all UDFs except those starting with apoc.any.prop:

GRANT EXECUTE USER DEFINED FUNCTIONS * ON DBMS TO deniedFunctionExecutor
DENY EXECUTE USER DEFINED FUNCTION apoc.any.prop* ON DBMS TO deniedFunctionExecutor

Or in short form:

GRANT EXECUTE FUNCTIONS * ON DBMS TO deniedFunctionExecutor
DENY EXECUTE FUNCTION apoc.any.prop* ON DBMS TO deniedFunctionExecutor

The resulting role has privileges that only allow the execution of all procedures except those starting with apoc.any.prop. List all privileges for the role deniedFunctionExecutor as commands by using the following query:

SHOW ROLE deniedFunctionExecutor PRIVILEGES AS COMMANDS
Table 53. Result
command

"DENY EXECUTE FUNCTION apoc.any.prop* ON DBMS TO `deniedFunctionExecutor`"

"GRANT EXECUTE FUNCTION * ON DBMS TO `deniedFunctionExecutor`"

Rows: 2

The apoc.any.property and apoc.any.properties are blocked, as well as any other procedures starting with apoc.any.prop.

The EXECUTE BOOSTED USER DEFINED FUNCTION privilege

The ability to use elevated privileges when executing a user-defined function (UDF) can be granted via the EXECUTE BOOSTED USER DEFINED FUNCTION privilege. A user with this privilege will not be restricted to their other privileges when executing the UDFs matched by the name-globbing. The EXECUTE BOOSTED USER DEFINED FUNCTION privilege only affects the elevation and not the execution of the function. Therefore, it is needed to grant EXECUTE USER DEFINED FUNCTION privilege for the functions as well.

Since Neo4j 5.0, both EXECUTE USER DEFINED FUNCTION and EXECUTE BOOSTED USER DEFINED FUNCTION are needed to execute a function with elevated privileges. This differs from Neo4j 4.x, when only the EXECUTE BOOSTED USER DEFINED FUNCTION is required.

The EXECUTE BOOSTED USER DEFINED FUNCTION privilege does not apply to built-in functions, as they have no concept of elevated privileges.

Example 7. Execute boosted user-defined function

The following query shows an example of how to grant the EXECUTE BOOSTED USER DEFINED FUNCTION privilege:

GRANT EXECUTE USER DEFINED FUNCTION * ON DBMS TO boostedFunctionExecutor
GRANT EXECUTE BOOSTED USER DEFINED FUNCTION apoc.any.properties ON DBMS TO boostedFunctionExecutor

Or in short form:

GRANT EXECUTE FUNCTION * ON DBMS TO boostedFunctionExecutor
GRANT EXECUTE BOOSTED FUNCTION apoc.any.properties ON DBMS TO boostedFunctionExecutor

Users with the role boostedFunctionExecutor can thus run apoc.any.properties with full privileges and see every property on the node/relationship, not just the properties that the user has READ privilege on. Without the EXECUTE USER DEFINED FUNCTION no UDFs could be executed at all.

The resulting role has privileges that allow executing the UDF apoc.any.properties with elevated privileges, and all other UDFs with the users' own privileges. List all privileges for the role boostedFunctionExecutor as commands by using the following query:

SHOW ROLE boostedFunctionExecutor PRIVILEGES AS COMMANDS
Table 54. Result
command

"GRANT EXECUTE FUNCTION * ON DBMS TO `boostedFunctionExecutor`"

"GRANT EXECUTE BOOSTED FUNCTION apoc.any.properties ON DBMS TO `boostedFunctionExecutor`"

Rows: 2

The DBMS SETTING privileges

The ability to show configuration settings can be granted via the SHOW SETTING privilege. A role with this privilege is allowed to query the configuration settings matched by the name-globbing.

For more details about the syntax descriptions, see Cypher syntax for administration commands.

Table 55. Setting privileges command syntax
Command Description
GRANT [IMMUTABLE] SHOW SETTING[S] name-globbing[, ...]
  ON DBMS
  TO role[, ...]

Enables the specified roles to query given configuration settings.

The following query shows an example of how to grant this privilege:

GRANT SHOW SETTING server.bolt.* ON DBMS TO configurationViewer

Users with the role configurationViewer can then query any setting in the server.bolt namespace.

The updated role configurationViewer has privileges that only allow querying settings in the server.bolt namespace. List all privileges for the role configurationViewer as commands by using the following query:

SHOW ROLE configurationViewer PRIVILEGES AS COMMANDS
Table 56. Result
command

"GRANT SHOW SETTING server.bolt.* ON DBMS TO `configurationViewer`"

Rows: 1

To deny a specific setting from a role, first grant SHOW SETTINGS *, and then deny the unwanted setting. For example, the following queries allow the querying of all settings, except those starting with dbms.security:

GRANT SHOW SETTINGS * ON DBMS TO deniedConfigurationViewer
DENY SHOW SETTING dbms.security* ON DBMS TO deniedConfigurationViewer

The resulting role has privileges that allow querying all settings except those starting with dbms.security. List all privileges for the role deniedConfigurationViewer as commands by using the following query:

SHOW ROLE deniedConfigurationViewer PRIVILEGES AS COMMANDS
Table 57. Result
command

"DENY SHOW SETTING dbms.security* ON DBMS TO `deniedConfigurationViewer`"

"GRANT SHOW SETTING * ON DBMS TO `deniedConfigurationViewer`"

Rows: 2

As the query result shows, access to any setting starting with dbms.security are blocked, but the rest can still be queried.

Granting ALL DBMS PRIVILEGES

The right to perform the following privileges can be achieved with a single command:

  • Create, drop, assign, remove, and show roles.

  • Create, alter, drop, show, and impersonate users.

  • Create, alter, and drop databases and aliases.

  • Enable, alter, rename, reallocate, deallocate, and drop servers

  • Show, assign, and remove privileges.

  • Execute all procedures with elevated privileges.

  • Execute all user-defined functions with elevated privileges.

  • Show all configuration settings.

For more details about the syntax descriptions, see Cypher syntax for administration commands.

GRANT [IMMUTABLE] ALL [[DBMS] PRIVILEGES]
    ON DBMS
    TO role[, ...]

For example, to grant the role dbmsManager the abilities above, use the following query:

GRANT ALL DBMS PRIVILEGES ON DBMS TO dbmsManager

The privileges granted can be seen using the SHOW PRIVILEGES command:

SHOW ROLE dbmsManager PRIVILEGES AS COMMANDS
Table 58. Result
command

"GRANT ALL DBMS PRIVILEGES ON DBMS TO `dbmsManager`"

Rows: 1

Name-globbing for procedures, user-defined functions, and settings

The name-globbing for procedures, user-defined functions, and setting names is a simplified version of globbing for filename expansions. It only allows two wildcard characters: * and ?, which are used for multiple and single-character matches. In this case, * means 0 or more characters, and ? matches exactly one character.

The name-globbing is subject to the Cypher Manual → Naming rules and recommendations, with the exception that it may include dots, stars, and question marks without the need for escaping using backticks.

Each part of the name-globbing separated by dots may be individually quoted. For example, mine.`procedureWith%` is allowed, but not mine.procedure`With%`. Also, note that wildcard characters behave as wildcards even when quoted. For example, using `*` is equivalent to using *, and thus allows executing all functions or procedures and not only the procedure or function named *.

Given the following list of procedures:

  • mine.public.exampleProcedure

  • mine.public.exampleProcedure1

  • mine.public.exampleProcedure2

  • mine.public.with#Special§Characters

  • mine.private.exampleProcedure

  • mine.private.exampleProcedure1

  • mine.private.exampleProcedure2

  • mine.private.with#Special§Characters

  • your.exampleProcedure

The following examples demonstrate how name-globbing patterns can be used in controlling access to procedures. Note that the same rules apply to user-defined functions and settings.

GRANT EXECUTE PROCEDURE * ON DBMS TO globbing1

Users with the role globbing1 can run all the procedures.

GRANT EXECUTE PROCEDURE mine.*.exampleProcedure ON DBMS TO globbing2

Users with the role globbing2 can run procedures mine.public.exampleProcedure and mine.private.exampleProcedure, but no other procedures.

GRANT EXECUTE PROCEDURE mine.*.exampleProcedure? ON DBMS TO globbing3

Users with the role globbing3 can run procedures mine.public.exampleProcedure1, mine.private.exampleProcedure1, and mine.private.exampleProcedure2, but no other procedures.

GRANT EXECUTE PROCEDURE *.exampleProcedure ON DBMS TO globbing4

Users with the role globbing4 can run procedures your.exampleProcedure, mine.public.exampleProcedure, and mine.private.exampleProcedure, but no other procedures.

GRANT EXECUTE PROCEDURE mine.public.exampleProcedure* ON DBMS TO globbing5

Users with the role globbing5 can run procedures mine.public.exampleProcedure, mine.public.exampleProcedure1 and mine.public.exampleProcedure42, but no other procedures.

GRANT EXECUTE PROCEDURE `mine.public.with#*§Characters`, mine.private.`with#Spec???§Characters` ON DBMS TO globbing6

Users with the role globbing6 can run procedures mine.public.with#Special§Characters, and mine.private.with#Special§Characters, but no other procedures.

The name-globbing may be fully or partially quoted. Both * and ? are interpreted as wildcards in both cases.