DBMS administration

This section explains how to use Cypher to manage Neo4j DBMS administrative 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 Neo4j databases and graphs.

grant privileges dbms
Figure 1. Syntax of GRANT and DENY DBMS Privileges
privilege 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.

  • Manage servers.

  • Change configuration parameters.

  • Manage transactions.

  • Manage users and roles.

  • Manage sub-graph privileges.

  • Manage procedure security.

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 doesn’t 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:

    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, 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.

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 user with this privilege is allowed to execute the SHOW ROLES and SHOW POPULATED ROLES administration commands.

In order to use SHOW ROLES WITH USERS and SHOW POPULATED ROLES WITH USERS administration commands, both this 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.

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 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 and SET STATUS parts:

ALTER USER jake SET PASSWORD 'secret' 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 'abc123' CHANGE NOT REQUIRED

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 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.

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.

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.

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

Enables the specified roles to delete standard databases.

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

Enables the specified roles to modify standard databases.

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.

The ability to create standard databases 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. 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 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. 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 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. 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 of 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 of 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 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. 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 are assignable using Cypher administrative commands and apply to both local and remote aliases. They can be granted, denied and revoked like other privileges. It is also possible to manage aliases with the database management commands.

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

Enable the specified roles to create new aliases.

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

Enable the specified roles to delete aliases.

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

Enable the specified roles to modify aliases.

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

Enable the specified roles to list aliases.

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

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

The ability to create aliases can be granted via the CREATE ALIAS privilege. The following query shows an example of this:

GRANT CREATE ALIAS ON DBMS TO aliasAdder

The resulting role has privileges that only allow creating aliases:

SHOW ROLE aliasAdder PRIVILEGES AS COMMANDS

Lists all privileges for role aliasAdder:

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. The following query shows an example of this:

GRANT DROP ALIAS ON DBMS TO aliasDropper

The resulting role has privileges that only allow deleting aliases:

SHOW ROLE aliasDropper PRIVILEGES AS COMMANDS

Lists all privileges for role aliasDropper:

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. The following query shows an example of this:

GRANT ALTER ALIAS ON DBMS TO aliasModifier

The resulting role has privileges that only allow modifying aliases:

SHOW ROLE aliasModifier PRIVILEGES AS COMMANDS

Lists all privileges for role aliasModifier:

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. The following query shows an example of this:

GRANT SHOW ALIAS ON DBMS TO aliasLister

The resulting role has privileges that only allow modifying aliases:

SHOW ROLE aliasLister PRIVILEGES AS COMMANDS

Lists all privileges for role aliasLister:

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. The following query shows an example of this:

GRANT ALIAS MANAGEMENT ON DBMS TO aliasManager

The resulting role has all privileges to manage aliases:

SHOW ROLE aliasManager PRIVILEGES AS COMMANDS

Lists all privileges for role aliasManager:

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.

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

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

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

Enables the specfied 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.

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.

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 execute the given procedures with elevated privileges.

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 execute the given user defined functions with elevated privileges.

The EXECUTE BOOSTED privileges replace the dbms.security.procedures.default_allowed and dbms.security.procedures.roles configuration parameters for procedures and user defined functions. The configuration parameters are still honored as a set of temporary privileges. These cannot be revoked, but will be updated on each restart with the current configuration values.

The EXECUTE PROCEDURE privilege

The ability to execute a procedure can be granted via the EXECUTE PROCEDURE privilege. A user 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.killTransaction:

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.killTransaction. 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

Both dbms.killTransaction and dbms.killTransactions are blocked here, as well as any other procedures starting with dbms.killTransaction.

The EXECUTE BOOSTED PROCEDURE privilege

The ability to execute a procedure with elevated privileges can be granted via the EXECUTE BOOSTED PROCEDURE privilege. A user with this privilege is allowed to execute the procedures matched by the name-globbing without the execution being restricted to their other privileges.

There is no need to grant an individual EXECUTE PROCEDURE privilege for the procedures either, as granting the EXECUTE BOOSTED PROCEDURE includes an implicit EXECUTE PROCEDURE grant for them. A denied EXECUTE PROCEDURE still denies executing the procedure. The following query shows an example of how to grant this privilege:

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 db.labels and db.relationshipTypes with full privileges. Now they can see everything on the graph and not just the labels and types that the user has TRAVERSE privilege on.

The resulting role has privileges that only allow executing procedures db.labels and db.relationshipTypes, but with elevated execution. List all privileges for the role boostedProcedureExecutor as commands by using the following query:

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

Granting the EXECUTE BOOSTED PROCEDURE privilege on its own allows the procedure to be both executed (due to the implicit EXECUTE PROCEDURE grant) and proceed with elevated privileges. A denied EXECUTE BOOSTED PROCEDURE on its own behaves slightly differently: it only denies the elevation and not the execution of the procedure. However, a role with both a granted EXECUTE BOOSTED PROCEDURE and a denied EXECUTE BOOSTED PROCEDURE will deny the execution as well. This is explained through 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 db.labels 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 executing all procedures with elevated privileges except db.labels, which is not allowed to be executed at all. 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 executing all procedures with elevated privileges except db.labels, which is not allowed to be executed at all. 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. Grant EXECUTE PROCEDURE and EXECUTE BOOSTED PROCEDURE and deny EXECUTE BOOSTED PROCEDURE
GRANT EXECUTE PROCEDURE db.labels ON DBMS TO deniedBoostedProcedureExecutor4
GRANT EXECUTE BOOSTED PROCEDURE * ON DBMS TO deniedBoostedProcedureExecutor4
DENY EXECUTE BOOSTED PROCEDURE db.labels ON DBMS TO deniedBoostedProcedureExecutor4

The resulting role has privileges that allow executing all procedures with elevated privileges except db.labels, which is only allowed to execute using the user’s own privileges. List all privileges for the role deniedBoostedProcedureExecutor4 as commands by using the following query:

SHOW ROLE deniedBoostedProcedureExecutor4 PRIVILEGES AS COMMANDS
Table 51. Result
command

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

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

"GRANT EXECUTE PROCEDURE db.labels ON DBMS TO `deniedBoostedProcedureExecutor4`"

Rows: 3

Example 5. How would the privileges from examples 1 to 4 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 4 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;

For comparison, when only EXECUTE BOOSTED PROCEDURE myProc is granted, the myProc procedure returns the result A, B and C, without the need for granting of the EXECUTE PROCEDURE myProc privilege.

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 to granting the EXECUTE BOOSTED PROCEDURE privilege 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 executing all admin procedures. List all privileges for the role adminProcedureExecutor as commands by using the following query:

SHOW ROLE adminProcedureExecutor PRIVILEGES AS COMMANDS
Table 52. 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 with the EXECUTE PROCEDURE myProc privilege, execution of the myProc procedure is not allowed.

However, for a user granted with the EXECUTE BOOSTED PROCEDURE myProc or EXECUTE ADMIN PROCEDURES privileges, 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 user 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 6. 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 53. 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 7. 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 54. 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 execute a user defined function (UDF) with elevated privileges can be granted via the EXECUTE BOOSTED USER DEFINED FUNCTION privilege. A user with this privilege is allowed to execute the UDFs matched by the name-globbing without the execution being restricted to their other privileges.

There is no need to grant an individual EXECUTE USER DEFINED FUNCTION privilege for the functions, as granting EXECUTE BOOSTED USER DEFINED FUNCTION includes an implicit EXECUTE USER DEFINED FUNCTION grant. However, a denied EXECUTE USER DEFINED FUNCTION still prevents the function to be executed.

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

Granting EXECUTE BOOSTED USER DEFINED FUNCTION on its own allows the UDF to be both executed (because of the implicit EXECUTE USER DEFINED FUNCTION grant) and gives it elevated privileges during the execution. A denied EXECUTE BOOSTED USER DEFINED FUNCTION on its own behaves slightly differently: it only denies the elevation and not the execution of the UDF. However, a role with only a granted EXECUTE BOOSTED USER DEFINED FUNCTION and a denied EXECUTE BOOSTED USER DEFINED FUNCTION prevents the execution to be performed as well. This is the same behavior as for the EXECUTE BOOSTED PROCEDURE privilege.

Example 8. 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.

The resulting role has privileges that only allow executing of the UDF apoc.any.properties, but with elevated execution. List all privileges for the role boostedFunctionExecutor as commands by using the following query:

SHOW ROLE boostedFunctionExecutor PRIVILEGES AS COMMANDS
Table 55. Result
command

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

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

Rows: 2

Procedure and user-defined function name-globbing

The name-globbing for procedure and user defined function 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 standard Cypher restrictions on valid identifiers, 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 escaped, for example, mine.`procedureWith%` but not mine.procedure`With%`. It is also good to keep in mind that wildcard characters behave as wildcards even when escaped. As an example, using `*` is equivalent to using *, and thus allows executing all functions or procedures and not only the procedure or function named *.

The examples below only use procedures, but the same rules apply to user defined function names:

  • 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

GRANT EXECUTE PROCEDURE * ON DBMS TO globbing1

Users with the role globbing1 can thus run all the procedures.

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

Users with the role globbing2 can thus run procedures mine.public.exampleProcedure and mine.private.exampleProcedure, but none of the others.

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

Users with the role globbing3 can thus run procedures mine.public.exampleProcedure1, mine.private.exampleProcedure1 and mine.private.exampleProcedure2, but none of the others.

GRANT EXECUTE PROCEDURE *.exampleProcedure ON DBMS TO globbing4

Users with the role globbing4 can thus run procedures your.exampleProcedure, mine.public.exampleProcedure and mine.private.exampleProcedure, but none of the others.

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

Users with the role globbing5 can thus run procedures mine.public.exampleProcedure, mine.public.exampleProcedure1 and mine.public.exampleProcedure42, but none of the others.

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

Users with the role globbing6 can thus run procedures mine.public.with#Special§Characters and mine.private.with#Special§Characters, but none of the others.

The name-globbing may be fully or partially escaped. Both * and ? are interpreted as wildcards either way.

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

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 56. Result
command

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

Rows: 1