DBMS administration

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 and drop databases.

  • Change configuration parameters.

  • Manage transactions.

  • Manage users and roles.

  • Manage sub-graph privileges.

  • Manage procedure security.

The easiest way to enable a user to perform these tasks is to grant them the admin role. All of these privileges are also assignable using Cypher® commands. See the sections on role management, user management, database management, privilege management, transaction management and procedure and user defined function security for details. It is possible to make a custom role with a subset of these privileges.

Using a custom role to manage DBMS privileges

If it is desired to have an administrator with a subset of privileges that includes all DBMS privileges, but not all database privileges, this can be achieved in multiple ways. One way is to copy the admin role and revoking or denying the unwanted privileges. A second option is to build a custom administrator from scratch by granting the wanted privileges instead.

As an example, let’s create an administrator that can only manage users and roles by using the latter option.

  1. First we create the new role:

    CREATE ROLE usermanager

  2. Then we 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:

SHOW ROLE usermanager PRIVILEGES AS COMMANDS

Lists all privileges for role usermanager:

Table 1. Result
command

"GRANT ROLE MANAGEMENT ON DBMS TO `usermanager`"

"GRANT USER MANAGEMENT ON DBMS TO `usermanager`"

Rows: 2

However, this role doesn’t allow all DBMS capabilities. For example, the role is missing privilege management, creating and dropping databases as well as executing admin procedures. We can make a more powerful administrator by granting a different set of privileges. Let’s create an administrator that can perform almost all DBMS capabilities, excluding database management, but also with some limited database capabilities, such as managing transactions:

  1. Again, we start by creating a new role:

    CREATE ROLE customAdministrator

  2. Then we 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. Thereafter we grant the transaction management privilege:

    GRANT TRANSACTION MANAGEMENT (*) ON DATABASE * TO customAdministrator

The resulting role has privileges that allow all DBMS privileges except creating and dropping databases, as well as managing transactions:

SHOW ROLE customAdministrator PRIVILEGES AS COMMANDS

Lists all privileges for role customAdministrator:

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 CREATE ROLE
  ON DBMS
  TO role[, ...]

Enable the specified roles to create new roles.

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

Enable the specified roles to change the name of roles.

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

Enable the specified roles to delete roles.

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

Enable the specified roles to assign roles to users.

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

Enable the specified roles to remove roles from users.

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

Enable the specified roles to list roles.

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

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

The ability to add roles can be granted via the CREATE ROLE privilege. The following query shows an example of this:

GRANT CREATE ROLE ON DBMS TO roleAdder

The resulting role has privileges that only allow adding roles:

SHOW ROLE roleAdder PRIVILEGES AS COMMANDS"

Lists all privileges for role roleAdder:

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

GRANT RENAME ROLE ON DBMS TO roleNameModifier

The resulting role has privileges that only allow renaming roles:

SHOW ROLE roleNameModifier PRIVILEGES AS COMMANDS

Lists all privileges for role roleNameModifier:

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

GRANT DROP ROLE ON DBMS TO roleDropper

The resulting role has privileges that only allow deleting roles:

SHOW ROLE roleDropper PRIVILEGES AS COMMANDS

Lists all privileges for role roleDropper:

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

GRANT ASSIGN ROLE ON DBMS TO roleAssigner

The resulting role has privileges that only allow assigning/granting roles:

SHOW ROLE roleAssigner PRIVILEGES AS COMMANDS"

Lists all privileges for role roleAssigner:

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

GRANT REMOVE ROLE ON DBMS TO roleRemover

The resulting role has privileges that only allow removing/revoking roles:

SHOW ROLE roleRemover PRIVILEGES AS COMMANDS

Lists all privileges for role roleRemover:

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

GRANT SHOW ROLE ON DBMS TO roleShower

The resulting role has privileges that only allow showing roles:

SHOW ROLE roleShower PRIVILEGES AS COMMANDS

Lists all privileges for role roleShower:

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

GRANT ROLE MANAGEMENT ON DBMS TO roleManager

The resulting role has all privileges to manage roles:

SHOW ROLE roleManager PRIVILEGES AS COMMANDS

Lists all privileges for role roleManager:

Table 10. Result
command

"GRANT ROLE MANAGEMENT ON DBMS TO `roleManager`"

Rows: 1

The DBMS USER MANAGEMENT privileges

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

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

Enable the specified roles to create new users.

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

Enable the specified roles to change the name of users.

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

Enable the specified roles to modify users.

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

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

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

Enable the specified roles to modify users' home database.

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

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

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

Enable the specified roles to delete users.

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

Enable the specified roles to list users.

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

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

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

GRANT CREATE USER ON DBMS TO userAdder

The resulting role has privileges that only allow adding users:

SHOW ROLE userAdder PRIVILEGES AS COMMANDS

Lists all privileges for role userAdder:

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

GRANT ALTER USER ON DBMS TO userModifier

The resulting role has privileges that only allow modifying users:

SHOW ROLE userModifier PRIVILEGES AS COMMANDS

Lists all privileges for role userModifier:

Table 14. Result
command

"GRANT ALTER USER ON DBMS TO `userModifier`"

Rows: 1

A user that is granted ALTER USER 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. The following query shows an example of this:

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:

SHOW ROLE passwordModifier PRIVILEGES AS COMMANDS

Lists all privileges for role passwordModifier:

Table 15. Result
command

"GRANT SET PASSWORD ON DBMS TO `passwordModifier`"

Rows: 1

A user that is granted SET PASSWORDS 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. The following query shows an example of this:

GRANT SET USER STATUS ON DBMS TO statusModifier

The resulting role has privileges that only allow modifying the account status of users:

SHOW ROLE statusModifier PRIVILEGES AS COMMANDS

Lists all privileges for role statusModifier:

Table 16. Result
command

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

Rows: 1

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

ALTER USER jake SET STATUS ACTIVE

The ability to modify the home database of users can be granted via the SET USER HOME DATABASE privilege. The following query shows an example of this:

GRANT SET USER HOME DATABASE ON DBMS TO statusModifier

The resulting role has privileges that only allow modifying the home database of users:

SHOW ROLE statusModifier PRIVILEGES AS COMMANDS

Lists all privileges for role statusModifier:

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

GRANT DROP USER ON DBMS TO userDropper

The resulting role has privileges that only allow deleting users:

SHOW ROLE userDropper PRIVILEGES AS COMMANDS

Lists all privileges for role userDropper:

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

GRANT SHOW USER ON DBMS TO userShower

The resulting role has privileges that only allow showing users:

SHOW ROLE userShower PRIVILEGES AS COMMANDS

Lists all privileges for role userShower:

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

GRANT USER MANAGEMENT ON DBMS TO userManager

The resulting role has all privileges to manage users:

SHOW ROLE userManager PRIVILEGES AS COMMANDS

The DBMS DATABASE MANAGEMENT privileges

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

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

Enable the specified roles to create new databases.

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

Enable the specified roles to delete databases.

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

Enable the specified roles to create and delete databases.

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

GRANT CREATE DATABASE ON DBMS TO databaseAdder

The resulting role has privileges that only allow creating databases:

SHOW ROLE databaseAdder PRIVILEGES AS COMMANDS

Lists all privileges for role databaseAdder:

Table 21. Result
command

"GRANT CREATE DATABASE ON DBMS TO `databaseAdder`"

Rows: 1

The ability to delete databases can be granted via the DROP DATABASE privilege. The following query shows an example of this:

GRANT DROP DATABASE ON DBMS TO databaseDropper

The resulting role has privileges that only allow deleting databases:

SHOW ROLE databaseDropper PRIVILEGES AS COMMANDS

Lists all privileges for role databaseDropper:

Table 22. Result
command

"GRANT DROP DATABASE ON DBMS TO `databaseDropper`"

Rows: 1

The privileges to create and delete databases can be granted via the DATABASE MANAGEMENT privilege. The following query shows an example of this:

GRANT DATABASE MANAGEMENT ON DBMS TO databaseManager

The resulting role has all privileges to manage databases:

SHOW ROLE databaseManager PRIVILEGES AS COMMANDS

Lists all privileges for role databaseManager:

Table 23. Result
command

"GRANT DATABASE MANAGEMENT ON DBMS TO `databaseManager`"

Rows: 1

The DBMS PRIVILEGE MANAGEMENT privileges

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

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

Enable the specified roles to list privileges.

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

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

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

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

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

Enable 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. "
For 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:

SHOW ROLE privilegeShower PRIVILEGES AS COMMANDS

Lists all privileges for role privilegeShower:

Table 25. 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 using either SHOW USER username PRIVILEGES, or SHOW USER PRIVILEGES.

Please note that if a non-native auth provider like LDAP is in use, SHOW USER PRIVILEGES will only work in a limited capacity; It is 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. The following query shows 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:

SHOW ROLE privilegeAssigner PRIVILEGES AS COMMANDS

Lists all privileges for role privilegeAssigner:

Table 26. 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. The following query shows 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:

SHOW ROLE privilegeRemover PRIVILEGES AS COMMANDS

Lists all privileges for role privilegeRemover:

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

GRANT PRIVILEGE MANAGEMENT ON DBMS TO privilegeManager

The resulting role has all privileges to manage privileges:

SHOW ROLE privilegeManager PRIVILEGES AS COMMANDS

Lists all privileges for role privilegeManager:

Table 28. 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 are assignable using Cypher administrative commands. They can be granted, denied and revoked like other privileges.

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

Enable the specified roles to execute the given procedures.

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

Enable the specified roles to execute the given procedures with elevated privileges.

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

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

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

Enable the specified roles to execute the given user defined functions.

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

Enable 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 honoured 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:

SHOW ROLE procedureExecutor PRIVILEGES AS COMMANDS

Lists all privileges for role procedureExecutor:

Table 30. Result
command

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

Rows: 1

If we want to allow executing all but a few procedures, we can grant EXECUTE PROCEDURES * and deny the unwanted procedures. For example, the following queries allow for executing all procedures, except those starting with dbms.killTransaction:

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

The resulting role has privileges that only allow executing all procedures except those starting with dbms.killTransaction:

SHOW ROLE deniedProcedureExecutor PRIVILEGES AS COMMANDS

Lists all privileges for role deniedProcedureExecutor:

Table 31. Result
command

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

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

Rows: 2

The dbms.killTransaction and dbms.killTransactions are blocked, 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 BOOSTED PROCEDURE db.labels, db.relationshipTypes ON DBMS TO boostedProcedureExecutor

Users with the role boostedProcedureExecutor can then run db.labels and db.relationshipTypes with full privileges, seeing everything in the graph 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:

SHOW ROLE boostedProcedureExecutor PRIVILEGES AS COMMANDS

Lists all privileges for role boostedProcedureExecutor:

Table 32. Result
command

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

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

Rows: 2

Granting EXECUTE BOOSTED PROCEDURE on its own allows the procedure to be both executed (because of the implicit EXECUTE PROCEDURE grant) and given elevated privileges during the execution. A denied EXECUTE BOOSTED PROCEDURE on its own behaves slightly differently, and only denies the elevation and not the execution of the procedure. However, a role with only 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 executing all procedures using the user’s own privileges, as well as blocking db.labels from being elevated. The deny EXECUTE BOOSTED PROCEDURE does not block execution of db.labels.

SHOW ROLE deniedBoostedProcedureExecutor1 PRIVILEGES AS COMMANDS

Lists all privileges for role deniedBoostedProcedureExecutor1:

Table 33. 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 execute at all:

SHOW ROLE deniedBoostedProcedureExecutor2 PRIVILEGES AS COMMANDS

Lists all privileges for role deniedBoostedProcedureExecutor2:

Table 34. 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 execute at all:

SHOW ROLE deniedBoostedProcedureExecutor3 PRIVILEGES AS COMMANDS

Lists all privileges for role deniedBoostedProcedureExecutor3:

Table 35. 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:

SHOW ROLE deniedBoostedProcedureExecutor4 PRIVILEGES AS COMMANDS
Table 36. 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?

Let’s assume there exists 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, let’s adapt the privileges in examples 1 to 4 to apply 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.

With the privileges from example 4, granted EXECUTE PROCEDURE myProc and EXECUTE BOOSTED PROCEDURE * and denied EXECUTE BOOSTED PROCEDURE myProc, the myProc procedure returns the result A and B.

For comparison, when only granted EXECUTE BOOSTED PROCEDURE myProc, the myProc procedure returns the result A, B and C, without needing to be granted 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 with granting the EXECUTE BOOSTED PROCEDURE privilege on each of the admin procedures. Any new admin procedures that gets added are 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:

SHOW ROLE adminProcedureExecutor PRIVILEGES AS COMMANDS

Lists all privileges for role adminProcedureExecutor:

Table 37. Result
command

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

Rows: 1

To compare this with the EXECUTE PROCEDURE and EXECUTE BOOSTED PROCEDURE privileges, let’s revisit the myProc procedure. This time as an admin procedure, which gives the result A, B and C when allowed to execute.

Let’s start with a user only granted the EXECUTE PROCEDURE myProc privilege, execution of the myProc procedure is not allowed.

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

Any denied execute privilege results in the procedure not being allowed to execute. It does not matter whether EXECUTE PROCEDURE, EXECUTE BOOSTED PROCEDURE or EXECUTE ADMIN PROCEDURES is 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 then run any UDF in the apoc.coll namespace. The function is run using the user’s own privileges.

The resulting role has privileges that only allow executing UDFs in the apoc.coll namespace:

SHOW ROLE functionExecutor PRIVILEGES AS COMMANDS

Lists all privileges for role functionExecutor:

Table 38. Result
command

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

Rows: 1

If you want to allow executing 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 for executing 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 executing all procedures except those starting with apoc.any.prop:

SHOW ROLE deniedFunctionExecutor PRIVILEGES AS COMMANDS

Lists all privileges for role deniedFunctionExecutor:

Table 39. 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 is 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 either, as granting the EXECUTE BOOSTED USER DEFINED FUNCTION includes an implicit EXECUTE USER DEFINED FUNCTION grant for them. A denied EXECUTE USER DEFINED FUNCTION still denies executing the function.

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 given elevated privileges during the execution. A denied EXECUTE BOOSTED USER DEFINED FUNCTION on its own behaves slightly differently, and 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 denies the execution 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 BOOSTED USER DEFINED FUNCTION apoc.any.properties ON DBMS TO boostedFunctionExecutor

Or in short form:

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

Users with the role boostedFunctionExecutor can then run apoc.any.properties with full privileges, seeing 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 the UDF apoc.any.properties, but with elevated execution:

SHOW ROLE boostedFunctionExecutor PRIVILEGES AS COMMANDS

Lists all privileges for role boostedFunctionExecutor:

Table 40. Result
command

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

Rows: 1

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, only allowing two wildcard characters; * and ?. They are used for multiple and single character matches, where * 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%`. Also good to keep in mind is that the 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. For the examples below, assume we have the following 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

GRANT EXECUTE PROCEDURE * ON DBMS TO globbing1

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

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

Users with the role globbing2 can then 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 then 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 then 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 then 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 then 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, and both the * 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 roles

  • drop roles

  • assign roles

  • remove roles

  • show roles

  • create users

  • alter users

  • drop users

  • show users

  • create databases

  • drop databases

  • show privileges

  • assign privileges

  • remove privileges

  • execute all procedures with elevated privileges

  • execute all user defined functions with elevated privileges

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

For example, granting the abilities above to the role dbmsManager is done using 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 41. Result
command

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

Rows: 1