Security of administration
This section explains how to use Cypher to manage Neo4j administrative privileges.
All of the commands described in the enclosing Administration section require that the user executing the commands has the rights to do so.
These privileges can be conferred either by granting the user the admin
role, which enables all administrative rights, or by granting specific combinations of privileges.
1. 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:
-
Manage multiple databases
-
Manage users and roles
-
Change configuration parameters
-
Manage sub-graph privileges
-
Manage procedure security
-
These rights are conferred using privileges that can be managed using GRANT
, DENY
and REVOKE
commands.
SHOW ROLE admin PRIVILEGES
access | action | resource | graph | segment | role |
---|---|---|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
9 rows |
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.
2. 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 byDEFAULT 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.
-
Command | Description |
---|---|
|
Grant a privilege to one or multiple roles. |
|
Deny a privilege to one or multiple roles. |
|
Revoke a granted privilege from one or multiple roles. |
|
Revoke a denied privilege from one or multiple roles. |
|
Revoke a granted or denied privilege from one or multiple roles. |
|
The hierarchy between the different database privileges is shown in the image below.

Command | Description |
---|---|
|
Grant the specified roles the privilege to access the default database, specific database(s), or all databases. |
|
Grant the specified roles the privilege to start and stop the default database, specific database(s), or all databases. |
|
Grant the specified roles the privilege to create, delete, or show indexes on the default database, specific database(s), or all databases. |
|
Grant the specified roles the privilege to manage indexes on the default database, specific database(s), or all databases. |
|
Grant the specified roles the privilege to create, delete, or show constraints on the default database, specific database(s), or all databases. |
|
Grant the specified roles the privilege to manage constraints on the default database, specific database(s), or all databases. |
|
Grant the specified roles the privilege to create new node labels in the default database, specific database(s), or all databases. |
|
Grant the specified roles the privilege to create new relationships types in the default database, specific database(s), or all databases. |
|
Grant the specified roles the privilege to create new property names in the default database, specific database(s), or all databases. |
|
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 the specified roles all privileges for the default database, specific database(s), or all databases. |
|
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 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. |

2.1. 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
.
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.
GRANT ACCESS
ON DATABASE neo4j TO regularUsers
0 rows, System updates: 1
The ACCESS
privilege can also be denied.
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.
DENY ACCESS
ON DATABASE neo4j TO regularUsers
0 rows, System updates: 1
The privileges granted can be seen using the SHOW PRIVILEGES
command:
SHOW ROLE regularUsers PRIVILEGES
access | action | resource | graph | segment | role |
---|---|---|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
2 rows |
2.2. The database START
/STOP
privileges
The START
privilege can be used to enable the ability to start a database.
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.
GRANT
START
ON DATABASE neo4j TO regularUsers
0 rows, System updates: 1
The START
privilege can also be denied.
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.
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.
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.
GRANT STOP
ON DATABASE neo4j TO regularUsers
0 rows, System updates: 1
The STOP
privilege can also be denied.
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.
DENY STOP
ON DATABASE system TO regularUsers
0 rows, System updates: 1
The privileges granted can be seen using the SHOW PRIVILEGES
command:
SHOW ROLE regularUsers PRIVILEGES
access | action | resource | graph | segment | role |
---|---|---|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
6 rows |
Note that |
2.3. 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.
Command | Description |
---|---|
|
Enable the specified roles to create, delete, or show indexes in the default database, specific database(s), or all databases. |
|
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.
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
.
2.4. 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.
Command | Description |
---|---|
|
Enable the specified roles to create, delete, or show constraints on the default database, specific database(s), or all databases. |
|
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.
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
.
2.5. 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.
Command | Description |
---|---|
|
Enable the specified roles to create new node labels in the default database, specific database(s), or all databases. |
|
Enable the specified roles to create new relationship types in the default database, specific database(s), or all databases. |
|
Enable the specified roles to create new property names in the default database, specific database(s), or all databases. |
|
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.
GRANT
CREATE NEW PROPERTY NAME
ON DATABASE neo4j TO regularUsers
0 rows, System updates: 1
2.6. 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:
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 |
For example, granting the abilities above on the database neo4j
to the role databaseAdminUsers
is done using the following 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:
SHOW ROLE databaseAdminUsers PRIVILEGES
access | action | resource | graph | segment | role |
---|---|---|---|---|---|
|
|
|
|
|
|
1 row |
2.7. 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.
Command | Description |
---|---|
|
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. |
|
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. |
|
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 |
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.
GRANT SHOW TRANSACTION(jake)
ON DATABASE neo4j TO regularUsers
0 rows, System updates: 1
3. 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.


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.
3.1. 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 by copying the admin
role and revoking or denying some privileges.
First we copy the 'admin' role:
CREATE ROLE usermanager AS COPY OF admin
0 rows, System updates: 2
Then we DENY ACCESS to normal databases:
DENY ACCESS
ON DATABASE * TO usermanager
0 rows, System updates: 1
And DENY START and STOP for normal databases:
DENY
START
ON DATABASE * TO usermanager
0 rows, System updates: 1
DENY STOP
ON DATABASE * TO usermanager
0 rows, System updates: 1
And DENY index and constraint management:
DENY INDEX MANAGEMENT
ON DATABASE * TO usermanager
0 rows, System updates: 1
DENY CONSTRAINT MANAGEMENT
ON DATABASE * TO usermanager
0 rows, System updates: 1
And finally DENY label, relationship type and property name:
DENY NAME MANAGEMENT
ON DATABASE * TO usermanager
0 rows, System updates: 1
The resulting role should have privileges that only allow the DBMS capabilities, like user and role management:
SHOW ROLE usermanager PRIVILEGES
Lists all privileges for role 'usermanager'
access | action | resource | graph | segment | role |
---|---|---|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
15 rows |
3.2. 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.
Command | Description |
---|---|
|
Enable the specified roles to create new roles. |
|
Enable the specified roles to delete roles. |
|
Enable the specified roles to assign roles to users. |
|
Enable the specified roles to remove roles from users. |
|
Enable the specified roles to list roles. |
|
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
0 rows, System updates: 1
The resulting role should have privileges that only allow adding roles:
SHOW ROLE roleAdder PRIVILEGES
Lists all privileges for role 'roleAdder'
access | action | resource | graph | segment | role |
---|---|---|---|---|---|
|
|
|
|
|
|
1 row |
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
0 rows, System updates: 1
The resulting role should have privileges that only allow deleting roles:
SHOW ROLE roleDropper PRIVILEGES
Lists all privileges for role 'roleDropper'
access | action | resource | graph | segment | role |
---|---|---|---|---|---|
|
|
|
|
|
|
1 row |
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
0 rows, System updates: 1
The resulting role should have privileges that only allow assigning/granting roles:
SHOW ROLE roleAssigner PRIVILEGES
Lists all privileges for role 'roleAssigner'
access | action | resource | graph | segment | role |
---|---|---|---|---|---|
|
|
|
|
|
|
1 row |
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
0 rows, System updates: 1
The resulting role should have privileges that only allow removing/revoking roles:
SHOW ROLE roleRemover PRIVILEGES
Lists all privileges for role 'roleRemover'
access | action | resource | graph | segment | role |
---|---|---|---|---|---|
|
|
|
|
|
|
1 row |
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
0 rows, System updates: 1
The resulting role should have privileges that only allow showing roles:
SHOW ROLE roleShower PRIVILEGES
Lists all privileges for role 'roleShower'
access | action | resource | graph | segment | role |
---|---|---|---|---|---|
|
|
|
|
|
|
1 row |
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:
GRANT ROLE MANAGEMENT
ON DBMS TO roleManager
0 rows, System updates: 1
The resulting role should have all privileges to manage roles:
SHOW ROLE roleManager PRIVILEGES
Lists all privileges for role 'roleManager'
access | action | resource | graph | segment | role |
---|---|---|---|---|---|
|
|
|
|
|
|
1 row |
3.3. 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.
Command | Description |
---|---|
|
Enable the specified roles to create new users. |
|
Enable the specified roles to delete users. |
|
Enable the specified roles to modify users. |
|
Enable the specified roles to modify users' passwords and whether those passwords must be changed upon first login. |
|
Enable the specified roles to modify the account status of users. |
|
Enable the specified roles to list users. |
|
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
0 rows, System updates: 1
The resulting role should have privileges that only allow adding users:
SHOW ROLE userAdder PRIVILEGES
Lists all privileges for role 'userAdder'
access | action | resource | graph | segment | role |
---|---|---|---|---|---|
|
|
|
|
|
|
1 row |
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
0 rows, System updates: 1
The resulting role should have privileges that only allow deleting users:
SHOW ROLE userDropper PRIVILEGES
Lists all privileges for role 'userDropper'
access | action | resource | graph | segment | role |
---|---|---|---|---|---|
|
|
|
|
|
|
1 row |
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
0 rows, System updates: 1
The resulting role should have privileges that only allow modifying users:
SHOW ROLE userModifier PRIVILEGES
Lists all privileges for role 'userModifier'
access | action | resource | graph | segment | role |
---|---|---|---|---|---|
|
|
|
|
|
|
1 row |
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
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:
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:
SHOW ROLE passwordModifier PRIVILEGES
Lists all privileges for role 'passwordModifier'
access | action | resource | graph | segment | role |
---|---|---|---|---|---|
|
|
|
|
|
|
1 row |
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
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:
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:
SHOW ROLE statusModifier PRIVILEGES
Lists all privileges for role 'statusModifier'
access | action | resource | graph | segment | role |
---|---|---|---|---|---|
|
|
|
|
|
|
1 row |
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
0 rows, System updates: 1
Note that the combination of the |
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
0 rows, System updates: 1
The resulting role should have privileges that only allow showing users:
SHOW ROLE userShower PRIVILEGES
Lists all privileges for role 'userShower'
access | action | resource | graph | segment | role |
---|---|---|---|---|---|
|
|
|
|
|
|
1 row |
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:
GRANT USER MANAGEMENT
ON DBMS TO userManager
0 rows, System updates: 1
The resulting role should have all privileges to manage users:
SHOW ROLE userManager PRIVILEGES
Lists all privileges for role 'userManager'
access | action | resource | graph | segment | role |
---|---|---|---|---|---|
|
|
|
|
|
|
1 row |
3.4. 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.
Command | Description |
---|---|
|
Enable the specified roles to create new databases. |
|
Enable the specified roles to delete databases. |
|
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
0 rows, System updates: 1
The resulting role should have privileges that only allow creating databases:
SHOW ROLE databaseAdder PRIVILEGES
Lists all privileges for role 'databaseAdder'
access | action | resource | graph | segment | role |
---|---|---|---|---|---|
|
|
|
|
|
|
1 row |
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
0 rows, System updates: 1
The resulting role should have privileges that only allow deleting databases:
SHOW ROLE databaseDropper PRIVILEGES
Lists all privileges for role 'databaseDropper'
access | action | resource | graph | segment | role |
---|---|---|---|---|---|
|
|
|
|
|
|
1 row |
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
0 rows, System updates: 1
The resulting role should have all privileges to manage databases:
SHOW ROLE databaseManager PRIVILEGES
Lists all privileges for role 'databaseManager'
access | action | resource | graph | segment | role |
---|---|---|---|---|---|
|
|
|
|
|
|
1 row |
3.5. 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.
Command | Description |
---|---|
|
Enable the specified roles to list privileges. |
|
Enable the specified roles to assign privileges using the |
|
Enable the specified roles to remove privileges using the |
|
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
0 rows, System updates: 1
The resulting role should have privileges that only allow showing privileges:
SHOW ROLE privilegeShower PRIVILEGES
Lists all privileges for role 'privilegeShower'
access | action | resource | graph | segment | role |
---|---|---|---|---|---|
|
|
|
|
|
|
1 row |
Note that no specific privileges are required for showing the current user’s privileges using either Please note that if a non-native auth provider like LDAP is in use, |
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
0 rows, System updates: 1
The resulting role should have privileges that only allow assigning privileges:
SHOW ROLE privilegeAssigner PRIVILEGES
Lists all privileges for role 'privilegeAssigner'
access | action | resource | graph | segment | role |
---|---|---|---|---|---|
|
|
|
|
|
|
1 row |
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
0 rows, System updates: 1
The resulting role should have privileges that only allow removing privileges:
SHOW ROLE privilegeRemover PRIVILEGES
Lists all privileges for role 'privilegeRemover'
access | action | resource | graph | segment | role |
---|---|---|---|---|---|
|
|
|
|
|
|
1 row |
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
0 rows, System updates: 1
The resulting role should have all privileges to manage privileges:
SHOW ROLE privilegeManager PRIVILEGES
Lists all privileges for role 'privilegeManager'
access | action | resource | graph | segment | role |
---|---|---|---|---|---|
|
|
|
|
|
|
1 row |
3.6. 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.
Command | Description |
---|---|
|
Enable the specified roles to execute the given procedures. |
|
Enable the specified roles to execute the given procedures with elevated privileges. |
|
Enable the specified roles to execute procedures annotated with |
|
Enable the specified roles to execute the given user defined functions. |
|
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.
3.6.1. 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
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 users own privileges.
The resulting role should have privileges that only allow executing procedures in the db.schema
namespace:
SHOW ROLE procedureExecutor PRIVILEGES
Lists all privileges for role 'procedureExecutor'
access | action | resource | graph | segment | role |
---|---|---|---|---|---|
|
|
|
|
|
|
1 row |
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 allows for executing all procedures except dbms.killTransaction
and dbms.killTransactions
:
GRANT EXECUTE PROCEDURE *
ON DBMS TO deniedProcedureExecutor
0 rows, System updates: 1
DENY EXECUTE PROCEDURE dbms.killTransaction*
ON DBMS TO deniedProcedureExecutor
0 rows, System updates: 1
The resulting role should have privileges that only allow executing all procedures except dbms.killTransaction
and dbms.killTransactions
:
SHOW ROLE deniedProcedureExecutor PRIVILEGES
Lists all privileges for role 'deniedProcedureExecutor'
access | action | resource | graph | segment | role |
---|---|---|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
2 rows |
3.6.2. 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.
The following query shows an example of how to grant this privilege:
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 should have privileges that only allow executing procedures db.labels
and db.relationshipTypes
, but with elevated execution:
SHOW ROLE boostedProcedureExecutor PRIVILEGES
Lists all privileges for role 'boostedProcedureExecutor'
access | action | resource | graph | segment | role |
---|---|---|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
2 rows |
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 different and only denies the elevation and not the execution. However, having only a granted EXECUTE BOOSTED PROCEDURE
and a deny 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
GRANT EXECUTE PROCEDURE *
ON DBMS TO deniedBoostedProcedureExecutor1
0 rows, System updates: 1
DENY EXECUTE BOOSTED PROCEDURE db.labels
ON DBMS TO deniedBoostedProcedureExecutor1
0 rows, System updates: 1
The resulting role should have 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
.
SHOW ROLE deniedBoostedProcedureExecutor1 PRIVILEGES
Lists all privileges for role 'deniedBoostedProcedureExecutor1'
access | action | resource | graph | segment | role |
---|---|---|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
2 rows |
Example 2: Grant EXECUTE BOOSTED PROCEDURE
and deny EXECUTE PROCEDURE
GRANT EXECUTE BOOSTED PROCEDURE *
ON DBMS TO deniedBoostedProcedureExecutor2
0 rows, System updates: 1
DENY EXECUTE PROCEDURE db.labels
ON DBMS TO deniedBoostedProcedureExecutor2
0 rows, System updates: 1
The resulting role should have privileges that allow executing all procedures with elevated privileges
except db.labels
which is not allowed to execute at all:
SHOW ROLE deniedBoostedProcedureExecutor2 PRIVILEGES
Lists all privileges for role 'deniedBoostedProcedureExecutor2'
access | action | resource | graph | segment | role |
---|---|---|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
2 rows |
Example 3: Grant EXECUTE BOOSTED PROCEDURE
and deny EXECUTE BOOSTED PROCEDURE
GRANT EXECUTE BOOSTED PROCEDURE *
ON DBMS TO deniedBoostedProcedureExecutor3
0 rows, System updates: 1
DENY EXECUTE BOOSTED PROCEDURE db.labels
ON DBMS TO deniedBoostedProcedureExecutor3
0 rows, System updates: 1
The resulting role should have privileges that allow executing all procedures with elevated privileges
except db.labels
which is not allowed to execute at all:
SHOW ROLE deniedBoostedProcedureExecutor3 PRIVILEGES
Lists all privileges for role 'deniedBoostedProcedureExecutor3'
access | action | resource | graph | segment | role |
---|---|---|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
2 rows |
Example 4: Grant EXECUTE PROCEDURE
and EXECUTE BOOSTED PROCEDURE
and deny EXECUTE BOOSTED PROCEDURE
GRANT EXECUTE PROCEDURE db.labels
ON DBMS TO deniedBoostedProcedureExecutor4
0 rows, System updates: 1
GRANT EXECUTE BOOSTED PROCEDURE *
ON DBMS TO deniedBoostedProcedureExecutor4
0 rows, System updates: 1
DENY EXECUTE BOOSTED PROCEDURE db.labels
ON DBMS TO deniedBoostedProcedureExecutor4
0 rows, System updates: 1
The resulting role should have privileges that allow executing all procedures with elevated privileges
except db.labels
which is only allowed to execute using the users own privileges:
SHOW ROLE deniedBoostedProcedureExecutor4 PRIVILEGES
Lists all privileges for role 'deniedBoostedProcedureExecutor4'
access | action | resource | graph | segment | role |
---|---|---|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
3 rows |
3.6.3. 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:
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 should have privileges that allows executing all admin procedures:
SHOW ROLE adminProcedureExecutor PRIVILEGES
Lists all privileges for role 'adminProcedureExecutor'
access | action | resource | graph | segment | role |
---|---|---|---|---|---|
|
|
|
|
|
|
1 row |
3.6.4. 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:
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 will be run using the users own privileges.
The resulting role should have privileges that only allow executing UDFs in the apoc.coll
namespace:
SHOW ROLE functionExecutor PRIVILEGES
Lists all privileges for role 'functionExecutor'
access | action | resource | graph | segment | role |
---|---|---|---|---|---|
|
|
|
|
|
|
1 row |
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 allows for executing all UDFs except apoc.any.property
and apoc.any.properties
:
GRANT EXECUTE FUNCTIONS *
ON DBMS TO deniedFunctionExecutor
0 rows, System updates: 1
DENY EXECUTE FUNCTION apoc.any.prop*
ON DBMS TO deniedFunctionExecutor
0 rows, System updates: 1
The resulting role should have privileges that only allow executing all procedures except apoc.any.property
and apoc.any.properties
:
SHOW ROLE deniedFunctionExecutor PRIVILEGES
Lists all privileges for role 'deniedFunctionExecutor'
access | action | resource | graph | segment | role |
---|---|---|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
2 rows |
3.6.5. 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.
The following query shows an example of how to grant this privilege:
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 should have privileges that only allow executing the UDF apoc.any.properties
, but with elevated execution:
SHOW ROLE boostedFunctionExecutor PRIVILEGES
Lists all privileges for role 'boostedFunctionExecutor'
access | action | resource | graph | segment | role |
---|---|---|---|---|---|
|
|
|
|
|
|
1 row |
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 different and only denies the elevation and not the execution. However, having only a granted EXECUTE BOOSTED USER DEFINED FUNCTION
and a deny EXECUTE BOOSTED USER DEFINED FUNCTION
will deny the execution as well.
This is the same behaviour as for EXECUTE BOOSTED PROCEDURE
, for examples see The EXECUTE BOOSTED PROCEDURE
privilege
3.6.6. 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 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.private.exampleProcedure
-
mine.private.exampleProcedure1
-
mine.private.exampleProcedure2
-
your.exampleProcedure
GRANT EXECUTE PROCEDURE *
ON DBMS TO globbing1
0 rows, System updates: 1
Users with the role 'globbing1' can then run procedures all the procedures.
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.
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.
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.
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.
3.7. 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
0 rows, System updates: 1
The privileges granted can be seen using the SHOW PRIVILEGES
command:
SHOW ROLE dbmsManager PRIVILEGES
access | action | resource | graph | segment | role |
---|---|---|---|---|---|
|
|
|
|
|
|
1 row |
Was this page helpful?