Security of administration

The admin role

The built-in role admin includes a number of privileges allowing users granted this role the ability to perform administrative tasks. These include the rights to perform the following classes of tasks:

  • Manage database security for controlling the rights to perform actions on specific databases:

    • Manage access to a database and the right to start and stop a database

    • Manage indexes and constraints

    • Allow the creation of labels, relationship types or property names

    • Manage transactions

  • Manage DBMS security for controlling the rights to perform actions on the entire system:

These rights are conferred using privileges that can be managed using GRANT, DENY and REVOKE commands.

Query
SHOW ROLE admin PRIVILEGES
Table 1. Result
access action resource graph segment role

"GRANTED"

"match"

"all_properties"

"*"

"NODE(*)"

"admin"

"GRANTED"

"write"

"graph"

"*"

"NODE(*)"

"admin"

"GRANTED"

"match"

"all_properties"

"*"

"RELATIONSHIP(*)"

"admin"

"GRANTED"

"write"

"graph"

"*"

"RELATIONSHIP(*)"

"admin"

"GRANTED"

"access"

"database"

"*"

"database"

"admin"

"GRANTED"

"admin"

"database"

"*"

"database"

"admin"

"GRANTED"

"constraint"

"database"

"*"

"database"

"admin"

"GRANTED"

"index"

"database"

"*"

"database"

"admin"

"GRANTED"

"token"

"database"

"*"

"database"

"admin"

Rows: 9

If the built-in admin role has been altered or dropped, and needs to be restored to its original state, see Operations Manual → Password and user recovery.

Database administration

The administrators can use the following Cypher® commands to manage Neo4j database administrative rights. The components of the database privilege commands are:

  • the command:

    • GRANT – gives privileges to roles.

    • DENY – denies privileges to roles.

    • REVOKE – removes granted or denied privilege from roles.

  • database-privilege

    • ACCESS - allows access to a specific database.

    • START - allows the specified database to be started.

    • STOP - allows the specified database to be stopped.

    • CREATE INDEX - allows indexes to be created on the specified database.

    • DROP INDEX - allows indexes to be deleted on the specified database.

    • SHOW INDEX - allows indexes to be listed on the specified database.

    • INDEX [MANAGEMENT] - allows indexes to be created, deleted, and listed on the specified database.

    • CREATE CONSTRAINT - allows constraints to be created on the specified database.

    • DROP CONSTRAINT - allows constraints to be deleted on the specified database.

    • SHOW CONSTRAINT - allows constraints to be listed on the specified database.

    • CONSTRAINT [MANAGEMENT] - allows constraints to be created, deleted, and listed on the specified database.

    • CREATE NEW [NODE] LABEL - allows labels to be created so that future nodes can be assigned them.

    • CREATE NEW [RELATIONSHIP] TYPE - allows relationship types to be created, so that future relationships can be created with these types.

    • CREATE NEW [PROPERTY] NAME - allows property names to be created, so that nodes and relationships can have properties with these names assigned.

    • NAME [MANAGEMENT] - allows all of the name management capabilities: node labels, relationship types, and property names.

    • ALL [[DATABASE] PRIVILEGES] - allows access, index, constraint, and name management for the specified database.

    • SHOW TRANSACTION - allows listing transactions and queries for the specified users on the specified database.

    • TERMINATE TRANSACTION - allows ending transactions and queries for the specified users on the specified database.

    • TRANSACTION [MANAGEMENT] - allows listing and ending transactions and queries for the specified users on the specified database.

  • name

    • The database to associate the privilege with.

      If you delete a database and create a new one with the same name, the new one will NOT have the privileges assigned to the deleted database.

    • The name component can be *, which means all databases. Databases created after this command execution will also be associated with these privileges.

    • The DATABASE[S] name part of the command can be replaced by DEFAULT DATABASE. If you restart the server and choose a new default database after this command execution, the new one will be associated with these privileges.

  • role[, …​]

    • The role or roles to associate the privilege with, comma-separated.

Table 2. General database privilege command syntax
Command Description
GRANT database-privilege ON {DEFAULT DATABASE | DATABASE[S] {* | name[, ...]}} TO role[, ...]

Grant a privilege to one or multiple roles.

DENY database-privilege ON {DEFAULT DATABASE | DATABASE[S] {* | name[, ...]}} TO role[, ...]

Deny a privilege to one or multiple roles.

REVOKE GRANT database-privilege ON {DEFAULT DATABASE | DATABASE[S] {* | name[, ...]}} FROM role[, ...]

Revoke a granted privilege from one or multiple roles.

REVOKE DENY database-privilege ON {DEFAULT DATABASE | DATABASE[S] {* | name[, ...]}} FROM role[, ...]

Revoke a denied privilege from one or multiple roles.

REVOKE database-privilege ON {DEFAULT DATABASE | DATABASE[S] {* | name[, ...]}} FROM role[, ...]

Revoke a granted or denied privilege from one or multiple roles.

DENY does NOT erase a granted privilege; they both exist. Use REVOKE if you want to remove a privilege.

The hierarchy between the different database privileges is shown in the image below.

privilege hierarchy database
Figure 1. Database privileges hierarchy
Table 3. Database privilege command syntax
Command Description
GRANT ACCESS
    ON {DEFAULT DATABASE | DATABASE[S] {* | name[, ...]}}
    TO role[, ...]

Grant the specified roles the privilege to access the default database, specific database(s), or all databases.

GRANT {START | STOP}
    ON {DEFAULT DATABASE | DATABASE[S] {* | name[, ...]}}
    TO role[, ...]

Grant the specified roles the privilege to start and stop the default database, specific database(s), or all databases.

GRANT {CREATE | DROP | SHOW} INDEX[ES]
    ON {DEFAULT DATABASE | DATABASE[S] {* | name[, ...]}}
    TO role[, ...]

Grant the specified roles the privilege to create, delete, or show indexes on the default database, specific database(s), or all databases.

GRANT INDEX[ES] [MANAGEMENT]
    ON {DEFAULT DATABASE | DATABASE[S] {* | name[, ...]}}
    TO role[, ...]

Grant the specified roles the privilege to manage indexes on the default database, specific database(s), or all databases.

GRANT {CREATE | DROP | SHOW} CONSTRAINT[S]
    ON {DEFAULT DATABASE | DATABASE[S] {* | name[, ...]}}
    TO role[, ...]

Grant the specified roles the privilege to create, delete, or show constraints on the default database, specific database(s), or all databases.

GRANT CONSTRAINT[S] [MANAGEMENT]
    ON {DEFAULT DATABASE | DATABASE[S] {* | name[, ...]}}
    TO role[, ...]

Grant the specified roles the privilege to manage constraints on the default database, specific database(s), or all databases.

GRANT CREATE NEW [NODE] LABEL[S]
    ON {DEFAULT DATABASE | DATABASE[S] {* | name[, ...]}}
    TO role[, ...]

Grant the specified roles the privilege to create new node labels in the default database, specific database(s), or all databases.

GRANT CREATE NEW [RELATIONSHIP] TYPE[S]
    ON {DEFAULT DATABASE | DATABASE[S] {* | name[, ...]}}
    TO role[, ...]

Grant the specified roles the privilege to create new relationships types in the default database, specific database(s), or all databases.

GRANT CREATE NEW [PROPERTY] NAME[S]
    ON {DEFAULT DATABASE | DATABASE[S] {* | name[, ...]}}
    TO role[, ...]

Grant the specified roles the privilege to create new property names in the default database, specific database(s), or all databases.

GRANT NAME [MANAGEMENT]
    ON {DEFAULT DATABASE | DATABASE[S] {* | name[, ...]}}
    TO role[, ...]

Grant the specified roles the privilege to manage new labels, relationship types, and property names in the default database, specific database(s), or all databases.

GRANT ALL [[DATABASE] PRIVILEGES]
    ON {DEFAULT DATABASE | DATABASE[S] {* | name[, ...]}}
    TO role[, ...]

Grant the specified roles all privileges for the default database, specific database(s), or all databases.

GRANT {SHOW | TERMINATE} TRANSACTION[S] [( {* | user[, ...]} )]
ON {DEFAULT DATABASE | DATABASE[S] {* | name[, ...]}}
TO role[, ...]

Grant the specified roles the privilege to list and end the transactions and queries of all users or a particular user(s) in the default database, specific database(s), or all databases.

GRANT TRANSACTION [MANAGEMENT] [( {* | user[, ...]} )]
ON {DEFAULT DATABASE | DATABASE[S] {* | name[, ...]}}
TO role[, ...]

Grant the specified roles the privilege to manage the transactions and queries of all users or a particular user(s) in the default database, specific database(s), or all databases.

grant privileges database
Figure 2. Syntax of GRANT and DENY Database Privileges

The database ACCESS privilege

The ACCESS privilege enables users to connect to a database. With ACCESS you can run calculations, for example, RETURN 2*5 AS answer or call functions RETURN timestamp() AS time.

Command syntax
GRANT ACCESS
    ON {DEFAULT DATABASE | DATABASE[S] {* | name[, ...]}}
    TO role[, ...]

For example, granting the ability to access the database neo4j to the role regularUsers is done using the following query.

Query
GRANT ACCESS ON DATABASE neo4j TO regularUsers

0 rows, System updates: 1

The ACCESS privilege can also be denied.

Command syntax
DENY ACCESS
    ON {DEFAULT DATABASE | DATABASE[S] {* | name[, ...]}}
    TO role[, ...]

For example, denying the ability to access to the database neo4j to the role regularUsers is done using the following query.

Query
DENY ACCESS ON DATABASE neo4j TO regularUsers

0 rows, System updates: 1

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

Query
SHOW ROLE regularUsers PRIVILEGES
Table 4. Result
access action resource graph segment role

"DENIED"

"access"

"database"

"neo4j"

"database"

"regularUsers"

"GRANTED"

"access"

"database"

"neo4j"

"database"

"regularUsers"

Rows: 2

The database START/STOP privileges

The START privilege can be used to enable the ability to start a database.

Command syntax
GRANT START
    ON {DEFAULT DATABASE | DATABASE[S] {* | name[, ...]}}
    TO role[, ...]

For example, granting the ability to start the database neo4j to the role regularUsers is done using the following query.

Query
GRANT START ON DATABASE neo4j TO regularUsers

0 rows, System updates: 1

The START privilege can also be denied.

Command syntax
DENY START
    ON {DEFAULT DATABASE | DATABASE[S] {* | name[, ...]}}
    TO role[, ...]

For example, denying the ability to start to the database neo4j to the role regularUsers is done using the following query.

Query
DENY START ON DATABASE system TO regularUsers

0 rows, System updates: 1

The STOP privilege can be used to enable the ability to stop a database.

Command syntax
GRANT STOP
    ON {DEFAULT DATABASE | DATABASE[S] {* | name[, ...]}}
    TO role[, ...]

For example, granting the ability to stop the database neo4j to the role regularUsers is done using the following query.

Query
GRANT STOP ON DATABASE neo4j TO regularUsers

0 rows, System updates: 1

The STOP privilege can also be denied.

Command syntax
DENY STOP
    ON {DEFAULT DATABASE | DATABASE[S] {* | name[, ...]}}
    TO role[, ...]

For example, denying the ability to stop to the database neo4j to the role regularUsers is done using the following query.

Query
DENY STOP ON DATABASE system TO regularUsers

0 rows, System updates: 1

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

Query
SHOW ROLE regularUsers PRIVILEGES
Table 5. Result
access action resource graph segment role

"DENIED"

"access"

"database"

"neo4j"

"database"

"regularUsers"

"GRANTED"

"access"

"database"

"neo4j"

"database"

"regularUsers"

"GRANTED"

"start_database"

"database"

"neo4j"

"database"

"regularUsers"

"GRANTED"

"stop_database"

"database"

"neo4j"

"database"

"regularUsers"

"DENIED"

"start_database"

"database"

"system"

"database"

"regularUsers"

"DENIED"

"stop_database"

"database"

"system"

"database"

"regularUsers"

Rows: 6

Note that START and STOP privileges are not included in the ALL DATABASE PRIVILEGES.

The INDEX MANAGEMENT privileges

Indexes can be created, deleted, or listed with the CREATE INDEX, DROP INDEX, and SHOW INDEXES commands. The privilege to do this can be granted with GRANT CREATE INDEX, GRANT DROP INDEX, and GRANT SHOW INDEX commands. The privilege to do all three can be granted with GRANT INDEX MANAGEMENT command.

Table 6. Index management command syntax
Command Description
GRANT {CREATE | DROP | SHOW} INDEX[ES]
    ON {DEFAULT DATABASE | DATABASE[S] {* | name[, ...]}}
    TO role[, ...]

Enable the specified roles to create, delete, or show indexes in the default database, specific database(s), or all databases.

GRANT INDEX[ES] [MANAGEMENT]
    ON {DEFAULT DATABASE | DATABASE[S] {* | name[, ...]}}
    TO role[, ...]

Enable the specified roles to manage indexes in the default database, specific database(s), or all databases.

For example, granting the ability to create indexes on the database neo4j to the role regularUsers is done using the following query.

Query
GRANT CREATE INDEX ON DATABASE neo4j TO regularUsers

0 rows, System updates: 1

The SHOW INDEXES privilege only affects the SHOW INDEXES command and not the old procedures for listing indexes, such as db.indexes.

The CONSTRAINT MANAGEMENT privileges

Constraints can be created, deleted, or listed with the CREATE CONSTRAINT, DROP CONSTRAINT and SHOW CONSTRAINTS commands. The privilege to do this can be granted with GRANT CREATE CONSTRAINT, GRANT DROP CONSTRAINT, GRANT SHOW CONSTRAINT commands. The privilege to do all three can be granted with GRANT CONSTRAINT MANAGEMENT command.

Table 7. Constraint management command syntax
Command Description
GRANT {CREATE | DROP | SHOW} CONSTRAINT[S]
    ON {DEFAULT DATABASE | DATABASE[S] {* | name[, ...]}}
    TO role[, ...]

Enable the specified roles to create, delete, or show constraints on the default database, specific database(s), or all databases.

GRANT CONSTRAINT[S] [MANAGEMENT]
    ON {DEFAULT DATABASE | DATABASE[S] {* | name[, ...]}}
    TO role[, ...]

Enable the specified roles to manage constraints on the default database, specific database(s), or all databases.

For example, granting the ability to create constraints on the database neo4j to the role regularUsers is done using the following query.

Query
GRANT CREATE CONSTRAINT ON DATABASE neo4j TO regularUsers

0 rows, System updates: 1

The SHOW CONSTRAINTS privilege only affects the SHOW CONSTRAINTS command and not the old procedures for listing constraints, such as db.constraints.

The NAME MANAGEMENT privileges

The right to create new labels, relationship types, and property names is different from the right to create nodes, relationships, and properties. The latter is managed using database WRITE privileges, while the former is managed using specific GRANT/DENY CREATE NEW …​ commands for each type.

Table 8. Label, relationship type and property name management command syntax
Command Description
GRANT CREATE NEW [NODE] LABEL[S]
    ON {DEFAULT DATABASE | DATABASE[S] {* | name[, ...]}}
    TO role[, ...]

Enable the specified roles to create new node labels in the default database, specific database(s), or all databases.

GRANT CREATE NEW [RELATIONSHIP] TYPE[S]
    ON {DEFAULT DATABASE | DATABASE[S] {* | name[, ...]}}
    TO role[, ...]

Enable the specified roles to create new relationship types in the default database, specific database(s), or all databases.

GRANT CREATE NEW [PROPERTY] NAME[S]
    ON {DEFAULT DATABASE | DATABASE[S] {* | name[, ...]}}
    TO role[, ...]

Enable the specified roles to create new property names in the default database, specific database(s), or all databases.

GRANT NAME [MANAGEMENT]
    ON {DEFAULT DATABASE | DATABASE[S] {* | name[, ...]}}
    TO role[, ...]

Enable the specified roles to create new labels, relationship types, and property names in the default database, specific database(s), or all databases.

For example, granting the ability to create new properties on nodes or relationships in the database neo4j to the role regularUsers is done using the following query.

Query
GRANT CREATE NEW PROPERTY NAME ON DATABASE neo4j TO regularUsers

0 rows, System updates: 1

Granting ALL DATABASE PRIVILEGES

The right to access a database, create and drop indexes and constraints and create new labels, relationship types or property names can be achieved with a single command:

Command syntax
GRANT ALL [[DATABASE] PRIVILEGES]
    ON {DEFAULT DATABASE | DATABASE[S] {* | name[, ...]}}
    TO role[, ...]

Note that the privileges for starting and stopping all databases, and transaction management, are not included in the ALL DATABASE PRIVILEGES grant. These privileges are associated with administrators while other database privileges are of use to domain and application developers.

For example, granting the abilities above on the database neo4j to the role databaseAdminUsers is done using the following query.

Query
GRANT ALL DATABASE PRIVILEGES ON DATABASE neo4j TO databaseAdminUsers

0 rows, System updates: 1

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

Query
SHOW ROLE databaseAdminUsers PRIVILEGES
Table 9. Result
access action resource graph segment role

"GRANTED"

"database_actions"

"database"

"neo4j"

"database"

"databaseAdminUsers"

Rows: 1

Granting TRANSACTION MANAGEMENT privileges

The right to run the procedures dbms.listTransactions, dbms.listQueries, dbms.killQuery, dbms.killQueries, dbms.killTransaction and dbms.killTransactions are managed through the SHOW TRANSACTION and TERMINATE TRANSACTION privileges.

Table 10. Transaction management command syntax
Command Description
GRANT SHOW TRANSACTION[S] [( {* | user[, ...]} )]
    ON {DEFAULT DATABASE | DATABASE[S] {* | name[, ...]}}
    TO role[, ...]

Enable the specified roles to list transactions and queries for user(s) or all users in the default database, specific database(s), or all databases.

GRANT TERMINATE TRANSACTION[S] [( {* | user[, ...]} )]
    ON {DEFAULT DATABASE | DATABASE[S] {* | name[, ...]}}
    TO role[, ...]

Enable the specified roles to end running transactions and queries for user(s) or all users in the default database, specific database(s), or all databases.

GRANT TRANSACTION [MANAGEMENT] [( {* | user[, ...]} )]
    ON {DEFAULT DATABASE | DATABASE[S] {* | name[, ...]}}
    TO role[, ...]

Enable the specified roles to manage transactions and queries for user(s) or all users in the default database, specific database(s), or all databases.

Note that the TRANSACTION MANAGEMENT privileges are not included in the ALL DATABASE PRIVILEGES.

For example, granting the ability to list transactions for user jake in the database neo4j to the role regularUsers is done using the following query.

Query
GRANT SHOW TRANSACTION (jake) ON DATABASE neo4j TO regularUsers

0 rows, System updates: 1

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

As described above, 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.

First we create the new role:

Query
CREATE ROLE usermanager

0 rows, System updates: 1

Then we grant the privilege to manage users:

Query
GRANT USER MANAGEMENT ON DBMS TO usermanager

0 rows, System updates: 1

And to manage roles:

Query
GRANT ROLE MANAGEMENT ON DBMS TO usermanager

0 rows, System updates: 1

The resulting role has privileges that only allow user and role management:

Query
SHOW ROLE usermanager PRIVILEGES

Lists all privileges for role 'usermanager'

Table 11. Result
access action resource graph segment role

"GRANTED"

"role_management"

"database"

"*"

"database"

"usermanager"

"GRANTED"

"user_management"

"database"

"*"

"database"

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

Again, we start by creating a new role:

Query
CREATE ROLE customAdministrator

0 rows, System updates: 1

Then we grant the privilege for all DBMS capabilities:

Query
GRANT ALL DBMS PRIVILEGES ON DBMS TO customAdministrator

0 rows, System updates: 1

And explicitly deny the privilege to manage databases:

Query
DENY DATABASE MANAGEMENT ON DBMS TO customAdministrator

0 rows, System updates: 1

Thereafter we grant the transaction management privilege:

Query
GRANT TRANSACTION MANAGEMENT (*) ON DATABASE * TO customAdministrator

0 rows, System updates: 1

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

Query
SHOW ROLE customAdministrator PRIVILEGES

Lists all privileges for role 'customAdministrator'

Table 12. Result
access action resource graph segment role

"GRANTED"

"transaction_management"

"database"

"*"

"USER(*)"

"customAdministrator"

"DENIED"

"database_management"

"database"

"*"

"database"

"customAdministrator"

"GRANTED"

"dbms_actions"

"database"

"*"

"database"

"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 13. Role management privileges command syntax
Command Description
GRANT CREATE ROLE
    ON DBMS
    TO role[, ...]

Enable the specified roles to create new 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:

Query
GRANT CREATE ROLE ON DBMS TO roleAdder

0 rows, System updates: 1

The resulting role should have privileges that only allow adding roles:

Query
SHOW ROLE roleAdder PRIVILEGES

Lists all privileges for role 'roleAdder'

Table 14. Result
access action resource graph segment role

"GRANTED"

"create_role"

"database"

"*"

"database"

"roleAdder"

Rows: 1

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

Query
GRANT DROP ROLE ON DBMS TO roleDropper

0 rows, System updates: 1

The resulting role should have privileges that only allow deleting roles:

Query
SHOW ROLE roleDropper PRIVILEGES

Lists all privileges for role 'roleDropper'

Table 15. Result
access action resource graph segment role

"GRANTED"

"drop_role"

"database"

"*"

"database"

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

Query
GRANT ASSIGN ROLE ON DBMS TO roleAssigner

0 rows, System updates: 1

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

Query
SHOW ROLE roleAssigner PRIVILEGES

Lists all privileges for role 'roleAssigner'

Table 16. Result
access action resource graph segment role

"GRANTED"

"assign_role"

"database"

"*"

"database"

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

Query
GRANT REMOVE ROLE ON DBMS TO roleRemover

0 rows, System updates: 1

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

Query
SHOW ROLE roleRemover PRIVILEGES

Lists all privileges for role 'roleRemover'

Table 17. Result
access action resource graph segment role

"GRANTED"

"remove_role"

"database"

"*"

"database"

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

Query
GRANT SHOW ROLE ON DBMS TO roleShower

0 rows, System updates: 1

The resulting role should have privileges that only allow showing roles:

Query
SHOW ROLE roleShower PRIVILEGES

Lists all privileges for role 'roleShower'

Table 18. Result
access action resource graph segment role

"GRANTED"

"show_role"

"database"

"*"

"database"

"roleShower"

Rows: 1

The privileges to create, delete, assign, remove, and list roles can be granted via the ROLE MANAGEMENT privilege. The following query shows an example of this:

Query
GRANT ROLE MANAGEMENT ON DBMS TO roleManager

0 rows, System updates: 1

The resulting role should have all privileges to manage roles:

Query
SHOW ROLE roleManager PRIVILEGES

Lists all privileges for role 'roleManager'

Table 19. Result
access action resource graph segment role

"GRANTED"

"role_management"

"database"

"*"

"database"

"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 20. User management privileges command syntax
Command Description
GRANT CREATE USER
    ON DBMS
    TO role[, ...]

Enable the specified roles to create new users.

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

Enable the specified roles to delete 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 STATUS
    ON DBMS
    TO role[, ...]

Enable the specified roles to modify the account status of 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:

Query
GRANT CREATE USER ON DBMS TO userAdder

0 rows, System updates: 1

The resulting role should have privileges that only allow adding users:

Query
SHOW ROLE userAdder PRIVILEGES

Lists all privileges for role 'userAdder'

Table 21. Result
access action resource graph segment role

"GRANTED"

"create_user"

"database"

"*"

"database"

"userAdder"

Rows: 1

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

Query
GRANT DROP USER ON DBMS TO userDropper

0 rows, System updates: 1

The resulting role should have privileges that only allow deleting users:

Query
SHOW ROLE userDropper PRIVILEGES

Lists all privileges for role 'userDropper'

Table 22. Result
access action resource graph segment role

"GRANTED"

"drop_user"

"database"

"*"

"database"

"userDropper"

Rows: 1

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

Query
GRANT ALTER USER ON DBMS TO userModifier

0 rows, System updates: 1

The resulting role should have privileges that only allow modifying users:

Query
SHOW ROLE userModifier PRIVILEGES

Lists all privileges for role 'userModifier'

Table 23. Result
access action resource graph segment role

"GRANTED"

"alter_user"

"database"

"*"

"database"

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

Query
ALTER USER jake SET PASSWORD 'secret' SET STATUS SUSPENDED

0 rows, System updates: 1

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:

Query
GRANT SET PASSWORDS ON DBMS TO passwordModifier

0 rows, System updates: 1

The resulting role should have privileges that only allow modifying users' passwords and whether those passwords must be changed upon first login:

Query
SHOW ROLE passwordModifier PRIVILEGES

Lists all privileges for role 'passwordModifier'

Table 24. Result
access action resource graph segment role

"GRANTED"

"set_passwords"

"database"

"*"

"database"

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

Query
ALTER USER jake SET PASSWORD 'abc123' CHANGE NOT REQUIRED

0 rows, System updates: 1

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:

Query
GRANT SET USER STATUS ON DBMS TO statusModifier

0 rows, System updates: 1

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

Query
SHOW ROLE statusModifier PRIVILEGES

Lists all privileges for role 'statusModifier'

Table 25. Result
access action resource graph segment role

"GRANTED"

"set_user_status"

"database"

"*"

"database"

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

Query
ALTER USER jake SET STATUS ACTIVE

0 rows, System updates: 1

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

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

Query
GRANT SHOW USER ON DBMS TO userShower

0 rows, System updates: 1

The resulting role should have privileges that only allow showing users:

Query
SHOW ROLE userShower PRIVILEGES

Lists all privileges for role 'userShower'

Table 26. Result
access action resource graph segment role

"GRANTED"

"show_user"

"database"

"*"

"database"

"userShower"

Rows: 1

The privileges to create, delete, modify, and list users can be granted via the USER MANAGEMENT privilege. The following query shows an example of this:

Query
GRANT USER MANAGEMENT ON DBMS TO userManager

0 rows, System updates: 1

The resulting role should have all privileges to manage users:

Query
SHOW ROLE userManager PRIVILEGES

Lists all privileges for role 'userManager'

Table 27. Result
access action resource graph segment role

"GRANTED"

"user_management"

"database"

"*"

"database"

"userManager"

Rows: 1

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

Query
GRANT CREATE DATABASE ON DBMS TO databaseAdder

0 rows, System updates: 1

The resulting role should have privileges that only allow creating databases:

Query
SHOW ROLE databaseAdder PRIVILEGES

Lists all privileges for role 'databaseAdder'

Table 29. Result
access action resource graph segment role

"GRANTED"

"create_database"

"database"

"*"

"database"

"databaseAdder"

Rows: 1

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

Query
GRANT DROP DATABASE ON DBMS TO databaseDropper

0 rows, System updates: 1

The resulting role should have privileges that only allow deleting databases:

Query
SHOW ROLE databaseDropper PRIVILEGES

Lists all privileges for role 'databaseDropper'

Table 30. Result
access action resource graph segment role

"GRANTED"

"drop_database"

"database"

"*"

"database"

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

Query
GRANT DATABASE MANAGEMENT ON DBMS TO databaseManager

0 rows, System updates: 1

The resulting role should have all privileges to manage databases:

Query
SHOW ROLE databaseManager PRIVILEGES

Lists all privileges for role 'databaseManager'

Table 31. Result
access action resource graph segment role

"GRANTED"

"database_management"

"database"

"*"

"database"

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

Query
GRANT SHOW PRIVILEGE ON DBMS TO privilegeShower

0 rows, System updates: 1

The resulting role should have privileges that only allow showing privileges:

Query
SHOW ROLE privilegeShower PRIVILEGES

Lists all privileges for role 'privilegeShower'

Table 33. Result
access action resource graph segment role

"GRANTED"

"show_privilege"

"database"

"*"

"database"

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

Query
GRANT ASSIGN PRIVILEGE ON DBMS TO privilegeAssigner

0 rows, System updates: 1

The resulting role should have privileges that only allow assigning privileges:

Query
SHOW ROLE privilegeAssigner PRIVILEGES

Lists all privileges for role 'privilegeAssigner'

Table 34. Result
access action resource graph segment role

"GRANTED"

"assign_privilege"

"database"

"*"

"database"

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

Query
GRANT REMOVE PRIVILEGE ON DBMS TO privilegeRemover

0 rows, System updates: 1

The resulting role should have privileges that only allow removing privileges:

Query
SHOW ROLE privilegeRemover PRIVILEGES

Lists all privileges for role 'privilegeRemover'

Table 35. Result
access action resource graph segment role

"GRANTED"

"remove_privilege"

"database"

"*"

"database"

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

Query
GRANT PRIVILEGE MANAGEMENT ON DBMS TO privilegeManager

0 rows, System updates: 1

The resulting role should have all privileges to manage privileges:

Query
SHOW ROLE privilegeManager PRIVILEGES

Lists all privileges for role 'privilegeManager'

Table 36. Result
access action resource graph segment role

"GRANTED"

"privilege_management"

"database"

"*"

"database"

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

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

0 rows, System updates: 1

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

The resulting role has privileges that only allow executing procedures in the db.schema namespace:

Query
SHOW ROLE procedureExecutor PRIVILEGES AS COMMANDS

Lists all privileges for role 'procedureExecutor'

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

Query
GRANT EXECUTE PROCEDURE * ON DBMS TO deniedProcedureExecutor

0 rows, System updates: 1

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

0 rows, System updates: 1

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

Query
SHOW ROLE deniedProcedureExecutor PRIVILEGES AS COMMANDS

Lists all privileges for role 'deniedProcedureExecutor'

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

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

0 rows, System updates: 2

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:

Query
SHOW ROLE boostedProcedureExecutor PRIVILEGES AS COMMANDS

Lists all privileges for role 'boostedProcedureExecutor'

Table 40. Result
command

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

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

Rows: 2

While granting EXECUTE BOOSTED PROCEDURE on its own allows the procedure to be both executed and given elevated privileges during the execution, the deny behaves slightly differently and only denies the elevation and not the execution. However, a user with only a granted EXECUTE BOOSTED PROCEDURE and a denied EXECUTE BOOSTED PROCEDURE will deny the execution as well. This is explained through the examples below:

Example 1: Grant EXECUTE PROCEDURE and deny EXECUTE BOOSTED PROCEDURE

Query
GRANT EXECUTE PROCEDURE * ON DBMS TO deniedBoostedProcedureExecutor1

0 rows, System updates: 1

Query
DENY EXECUTE BOOSTED PROCEDURE db.labels ON DBMS TO deniedBoostedProcedureExecutor1

0 rows, System updates: 1

The resulting role has privileges that allow executing all procedures using the users own privileges, as well as blocking db.labels from being elevated. The deny EXECUTE BOOSTED PROCEDURE does not block execution of db.labels.

Query
SHOW ROLE deniedBoostedProcedureExecutor1 PRIVILEGES AS COMMANDS

Lists all privileges for role 'deniedBoostedProcedureExecutor1'

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

Query
GRANT EXECUTE BOOSTED PROCEDURE * ON DBMS TO deniedBoostedProcedureExecutor2

0 rows, System updates: 1

Query
DENY EXECUTE PROCEDURE db.labels ON DBMS TO deniedBoostedProcedureExecutor2

0 rows, System updates: 1

The resulting role has privileges that allow executing all procedures with elevated privileges except db.labels which is not allowed to execute at all:

Query
SHOW ROLE deniedBoostedProcedureExecutor2 PRIVILEGES AS COMMANDS

Lists all privileges for role 'deniedBoostedProcedureExecutor2'

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

Query
GRANT EXECUTE BOOSTED PROCEDURE * ON DBMS TO deniedBoostedProcedureExecutor3

0 rows, System updates: 1

Query
DENY EXECUTE BOOSTED PROCEDURE db.labels ON DBMS TO deniedBoostedProcedureExecutor3

0 rows, System updates: 1

The resulting role has privileges that allow executing all procedures with elevated privileges except db.labels which is not allowed to execute at all:

Query
SHOW ROLE deniedBoostedProcedureExecutor3 PRIVILEGES AS COMMANDS

Lists all privileges for role 'deniedBoostedProcedureExecutor3'

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

Query
GRANT EXECUTE PROCEDURE db.labels ON DBMS TO deniedBoostedProcedureExecutor4

0 rows, System updates: 1

Query
GRANT EXECUTE BOOSTED PROCEDURE * ON DBMS TO deniedBoostedProcedureExecutor4

0 rows, System updates: 1

Query
DENY EXECUTE BOOSTED PROCEDURE db.labels ON DBMS TO deniedBoostedProcedureExecutor4

0 rows, System updates: 1

The resulting role has privileges that allow executing all procedures with elevated privileges except db.labels which is only allowed to execute using the users own privileges:

Query
SHOW ROLE deniedBoostedProcedureExecutor4 PRIVILEGES AS COMMANDS

Lists all privileges for role 'deniedBoostedProcedureExecutor4'

Table 44. 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 example 1-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 PROCEDURES 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:

Query
GRANT EXECUTE ADMIN PROCEDURES ON DBMS TO adminProcedureExecutor

0 rows, System updates: 1

Users with the role 'adminProcedureExecutor' can then run any admin procedure with elevated privileges.

The resulting role has privileges that allows executing all admin procedures:

Query
SHOW ROLE adminProcedureExecutor PRIVILEGES AS COMMANDS

Lists all privileges for role 'adminProcedureExecutor'

Table 45. 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 following query shows an example of how to grant this privilege:

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

0 rows, System updates: 1

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:

Query
SHOW ROLE functionExecutor PRIVILEGES AS COMMANDS

Lists all privileges for role 'functionExecutor'

Table 46. Result
command

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

Rows: 1

The EXECUTE USER DEFINED FUNCTION privileges do not apply to built-in functions which are always executable.

If we want to allow executing all but a few UDFs, we can grant EXECUTE USER DEFINED FUNCTIONS * and deny the unwanted functions. For example, the following queries allow for executing all UDFs except those starting with apoc.any.prop:

Query
GRANT EXECUTE FUNCTIONS * ON DBMS TO deniedFunctionExecutor

0 rows, System updates: 1

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

0 rows, System updates: 1

The resulting role has privileges that only allow executing all procedures except those starting with apoc.any.prop:

Query
SHOW ROLE deniedFunctionExecutor PRIVILEGES AS COMMANDS

Lists all privileges for role 'deniedFunctionExecutor'

Table 47. 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 following query shows an example of how to grant this privilege:

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

0 rows, System updates: 1

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:

Query
SHOW ROLE boostedFunctionExecutor PRIVILEGES AS COMMANDS

Lists all privileges for role 'boostedFunctionExecutor'

Table 48. Result
command

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

Rows: 1

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

While granting EXECUTE BOOSTED USER DEFINED FUNCTION on its own allows the UDF to be both executed and given elevated privileges during the execution, the deny behaves slightly differently and only denies the elevation and not the execution. However, a user 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 EXECUTE BOOSTED PROCEDURE, for examples see The EXECUTE BOOSTED PROCEDURE privilege

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

  • mine.public.with#Special§Characters

  • mine.private.exampleProcedure

  • mine.private.exampleProcedure1

  • mine.private.exampleProcedure2

  • mine.private.with#Special§Characters

  • your.exampleProcedure

Query
GRANT EXECUTE PROCEDURE * ON DBMS TO globbing1

0 rows, System updates: 1

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

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

0 rows, System updates: 1

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

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

0 rows, System updates: 1

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

Query
GRANT EXECUTE PROCEDURE *.exampleProcedure ON DBMS TO globbing4

0 rows, System updates: 1

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

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

0 rows, System updates: 1

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

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

0 rows, System updates: 2

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

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

For example, granting the abilities above to the role dbmsManager is done using the following query.

Query
GRANT ALL DBMS PRIVILEGES ON DBMS TO dbmsManager

0 rows, System updates: 1

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

Query
SHOW ROLE dbmsManager PRIVILEGES
Table 49. Result
access action resource graph segment role

"GRANTED"

"dbms_actions"

"database"

"*"

"database"

"dbmsManager"

Rows: 1