DBMS privileges
All DBMS privileges are relevant system-wide. Like user management, they do not belong to one specific database or graph. For more details on the differences between graphs, databases, and the DBMS, refer to Cypher Manual → Cypher and Neo4j.
The admin
role has a number of built-in privileges.
These include:
-
Create, delete, and modify databases and aliases.
-
Change configuration parameters.
-
Manage transactions.
-
Manage users and roles.
-
Manage sub-graph privileges.
-
Manage procedure security.
-
Load data.
To enable a user to perform these tasks, you can grant them the admin
role, but it is also possible to make a custom role with a subset of these privileges.
All privileges are also assignable using Cypher commands.
For more details, see the following sections:
Using a custom role to manage DBMS privileges
In order to have an administrator role with a subset of privileges that includes all DBMS privileges, but not all database privileges, you can copy the admin
role and revoke or deny the unwanted privileges.
A second option is to build a custom administrator from scratch by granting the wanted privileges instead.
As an example, an administrator role can be created to only manage users and roles by using the second option:
-
First, create the new role:
CREATE ROLE usermanager
-
Then grant the privilege to manage users:
GRANT USER MANAGEMENT ON DBMS TO usermanager
-
And to manage roles:
GRANT ROLE MANAGEMENT ON DBMS TO usermanager
The resulting role has privileges that only allow user and role management.
To list all privileges for the role usermanager
as commands, run this query:
SHOW ROLE usermanager PRIVILEGES AS COMMANDS
command |
---|
|
|
Rows: 2 |
Note that this role does not allow all DBMS capabilities.
For example, the role is missing privileges for management, creation and drop of databases as well as execution of admin
procedures.
To create a more powerful administrator, you can grant a different set of privileges.
In the following example, a new administrator role is created to perform almost all DBMS capabilities, excluding database management. However, the role still has some limited database capabilities, such as managing transactions:
-
Again, start by creating a new role:
CREATE ROLE customAdministrator
-
Then grant the privilege for all DBMS capabilities:
GRANT ALL DBMS PRIVILEGES ON DBMS TO customAdministrator
-
And explicitly deny the privilege to manage databases and aliases:
DENY DATABASE MANAGEMENT ON DBMS TO customAdministrator
-
Next, grant the transaction management privilege:
GRANT TRANSACTION MANAGEMENT (*) ON DATABASE * TO customAdministrator
The resulting role has privileges that include all DBMS privileges except creating, dropping, and modifying databases and aliases, as well as managing transactions.
Use the following query to list all privileges for the role customAdministrator
as commands:
SHOW ROLE customAdministrator PRIVILEGES AS COMMANDS
command |
---|
|
|
|
Rows: 3 |
The DBMS ROLE MANAGEMENT
privileges
The DBMS privileges for role management are assignable using Cypher administrative commands. They can be granted, denied, and revoked like other privileges.
For more details about the syntax descriptions, see Cypher syntax for administration commands. |
Command | Description |
---|---|
|
Enables the specified roles to create new roles. |
|
Enables the specified roles to change the name of roles. |
|
Enables the specified roles to delete roles. |
|
Enables the specified roles to assign roles to users. |
|
Enables the specified roles to remove roles from users. |
|
Enables the specified roles to list roles. |
|
Enables the specified roles to create, delete, assign, remove, and list roles. |
The ability to add roles can be granted via the CREATE ROLE
privilege.
See an example:
GRANT CREATE ROLE ON DBMS TO roleAdder
The resulting role has privileges that only allow adding roles.
List all privileges for the role roleAdder
as commands by using the following query:
SHOW ROLE roleAdder PRIVILEGES AS COMMANDS
command |
---|
|
Rows: 1 |
The ability to rename roles can be granted via the RENAME ROLE
privilege.
See an example:
GRANT RENAME ROLE ON DBMS TO roleNameModifier
The resulting role has privileges that only allow renaming roles.
List all privileges for the role roleNameModifier
using the following query:
SHOW ROLE roleNameModifier PRIVILEGES AS COMMANDS
command |
---|
|
Rows: 1 |
The ability to delete roles can be granted via the DROP ROLE
privilege.
See an example:
GRANT DROP ROLE ON DBMS TO roleDropper
The resulting role has privileges that only allow deleting roles.
List all privileges for the role roleDropper
by using the following query:
SHOW ROLE roleDropper PRIVILEGES AS COMMANDS
command |
---|
|
Rows: 1 |
The ability to assign roles to users can be granted via the ASSIGN ROLE
privilege.
See an example:
GRANT ASSIGN ROLE ON DBMS TO roleAssigner
The resulting role has privileges that only allow assigning/granting roles.
List all privileges for the role roleAssigner
as commands by using the following query:
SHOW ROLE roleAssigner PRIVILEGES AS COMMANDS
command |
---|
|
Rows: 1 |
The ability to remove roles from users can be granted via the REMOVE ROLE
privilege.
See an example:
GRANT REMOVE ROLE ON DBMS TO roleRemover
The resulting role has privileges that only allow removing/revoking roles.
List all privileges for the role roleRemover
as commands by using the following query:
SHOW ROLE roleRemover PRIVILEGES AS COMMANDS
command |
---|
|
Rows: 1 |
The ability to show roles can be granted via the SHOW ROLE
privilege.
A role with this privilege is allowed to execute the SHOW ROLES
and SHOW POPULATED ROLES
administration commands.
For the SHOW ROLES WITH USERS
and SHOW POPULATED ROLES WITH USERS
administration commands, both this privilege and the SHOW USER
privilege are required.
The following query shows an example of how to grant the SHOW ROLE
privilege:
In order to use SHOW ROLES WITH USERS
and SHOW POPULATED ROLES WITH USERS
administration commands, both the SHOW ROLE
and the SHOW USER
privileges are required.
See an example of how to grant the SHOW ROLE
privilege:
GRANT SHOW ROLE ON DBMS TO roleShower
The resulting role has privileges that only allow showing roles.
List all privileges for the role roleShower
as commands by using the following query:
SHOW ROLE roleShower PRIVILEGES AS COMMANDS
command |
---|
|
Rows: 1 |
The privileges to create, rename, delete, assign, remove, and list roles can be granted via the ROLE MANAGEMENT
privilege.
See an example:
GRANT ROLE MANAGEMENT ON DBMS TO roleManager
The resulting role has all privileges to manage roles.
List all privileges for the role roleManager
as commands by using the following query:
SHOW ROLE roleManager PRIVILEGES AS COMMANDS
command |
---|
|
Rows: 1 |
The DBMS USER MANAGEMENT
privileges
The DBMS privileges for user management can be assigned using Cypher administrative commands. They can be granted, denied, and revoked like other privileges.
For more details about the syntax descriptions, see Cypher syntax for administration commands. |
Command | Description |
---|---|
|
Enables the specified roles to create new users. |
|
Enables the specified roles to change the name of users. |
|
Enables the specified roles to modify users. |
|
Enables the specified roles to modify users' passwords and whether those passwords must be changed upon first login. |
|
Introduced in 5.24 Enables the specified roles to |
|
Enables the specified roles to modify users' home database. |
|
Enables the specified roles to modify the account status of users. |
|
Enables the specified roles to delete users. |
|
Enables the specified roles to list users. |
|
Enables the specified roles to create, delete, modify, and list users. |
The ability to add users can be granted via the CREATE USER
privilege.
See an example:
GRANT CREATE USER ON DBMS TO userAdder
The resulting role has privileges that only allow adding users.
List all privileges for the role userAdder
as commands by using this query:
SHOW ROLE userAdder PRIVILEGES AS COMMANDS
command |
---|
|
Rows: 1 |
The ability to rename users can be granted via the RENAME USER
privilege.
The following query shows an example of this:
GRANT RENAME USER ON DBMS TO userNameModifier
The resulting role has privileges that only allow renaming users:
SHOW ROLE userNameModifier PRIVILEGES AS COMMANDS
Lists all privileges for role userNameModifier
:
command |
---|
|
Rows: 1 |
The ability to modify users can be granted via the ALTER USER
privilege.
See an example:
GRANT ALTER USER ON DBMS TO userModifier
The resulting role has privileges that only allow modifying users.
List all privileges for the role userModifier
as commands by using the following query:
SHOW ROLE userModifier PRIVILEGES AS COMMANDS
command |
---|
|
Rows: 1 |
A user that is granted the ALTER USER
privilege is allowed to run the ALTER USER
administration command with one or several of the SET PASSWORD
, SET PASSWORD CHANGE [NOT] REQUIRED
, SET AUTH
, REMOVE AUTH
and SET STATUS
parts:
ALTER USER jake SET PASSWORD 'verysecret' SET STATUS SUSPENDED
The ability to modify users' passwords and whether those passwords must be changed upon first login can be granted via the SET PASSWORDS
privilege.
See an example:
GRANT SET PASSWORDS ON DBMS TO passwordModifier
The resulting role has privileges that only allow modifying users' passwords and whether those passwords must be changed upon first login.
List all privileges for the role passwordModifier
as commands by using the following query:
SHOW ROLE passwordModifier PRIVILEGES AS COMMANDS
command |
---|
|
Rows: 1 |
A user that is granted the SET PASSWORDS
privilege is allowed to run the ALTER USER
administration command with one or both of the SET PASSWORD
and SET PASSWORD CHANGE [NOT] REQUIRED
parts:
ALTER USER jake SET PASSWORD 'abcd5678' CHANGE NOT REQUIRED
Introduced in 5.24 A user that is granted the SET AUTH
privilege is allowed to run the ALTER USER
administration command with one or both of the SET AUTH
and REMOVE AUTH
parts:
ALTER USER jake REMOVE AUTH 'native SET AUTH 'oidc-okta' { SET id 'jakesUniqueOktaUserId' }
The ability to modify the account status of users can be granted via the SET USER STATUS
privilege.
See an example:
GRANT SET USER STATUS ON DBMS TO statusModifier
The resulting role has privileges that only allow modifying the account status of users.
List all privileges for the role statusModifier
as commands by using the following query:
SHOW ROLE statusModifier PRIVILEGES AS COMMANDS
command |
---|
|
Rows: 1 |
A user that is granted the SET USER STATUS
privilege is allowed to run the ALTER USER
administration command with only the SET STATUS
part:
ALTER USER jake SET STATUS ACTIVE
In order to be able to modify the home database of users, grant the SET USER HOME DATABASE
privilege.
See an example:
GRANT SET USER HOME DATABASE ON DBMS TO statusModifier
The resulting role has privileges that only allow modifying the home database of users.
List all privileges for the role statusModifier
as commands by using the following query:
SHOW ROLE statusModifier PRIVILEGES AS COMMANDS
command |
---|
|
|
Rows: 2 |
A user that is granted the SET USER HOME DATABASE
privilege is allowed to run the ALTER USER
administration command with only the SET HOME DATABASE
or REMOVE HOME DATABASE
part:
ALTER USER jake SET HOME DATABASE otherDb
ALTER USER jake REMOVE HOME DATABASE
Note that the combination of the |
The ability to delete users can be granted via the DROP USER
privilege.
See an example:
GRANT DROP USER ON DBMS TO userDropper
The resulting role has privileges that only allow deleting users.
List all privileges for the role userDropper
as commands by using the following query:
SHOW ROLE userDropper PRIVILEGES AS COMMANDS
command |
---|
|
Rows: 1 |
The ability to show users can be granted via the SHOW USER
privilege.
See an example:
GRANT SHOW USER ON DBMS TO userShower
The resulting role has privileges that only allow showing users.
List all privileges for the role userShower
as commands by using the following query:
SHOW ROLE userShower PRIVILEGES AS COMMANDS
command |
---|
|
Rows: 1 |
The privileges to create, rename, modify, delete, and list users can be granted via the USER MANAGEMENT
privilege.
See an example:
GRANT USER MANAGEMENT ON DBMS TO userManager
The resulting role has all privileges to manage users.
List all privileges for the role userManager
as commands by using the following query:
SHOW ROLE userManager PRIVILEGES AS COMMANDS
command |
---|
|
Rows: 1 |
The DBMS IMPERSONATE
privileges
The DBMS privileges for impersonation can be assigned through Cypher administrative commands. They can be granted, denied, and revoked like other privileges.
Impersonation is the ability of a user to assume another user’s roles (and therefore privileges), with the restriction of not being able to execute updating admin
commands as the impersonated user (i.e. they would still be able to use SHOW
commands).
The ability to impersonate users can be granted via the IMPERSONATE
privilege.
For more details about the syntax descriptions, see Cypher syntax for administration commands. |
Command | Description |
---|---|
|
Enables the specified roles to impersonate any user. |
|
Enables the specified roles to impersonate the specified users. |
The following query shows an example of this.
Note that userImpersonator
must be an existing role in order to make this query work:
GRANT IMPERSONATE (*) ON DBMS TO userImpersonator
The resulting role has privileges that allow impersonating all users:
SHOW ROLE userImpersonator PRIVILEGES AS COMMANDS
command |
---|
|
Rows: 1 |
It is also possible to deny and revoke that privilege.
See an example which shows of how the userImpersonator
user would be able to impersonate all users, except alice
:
DENY IMPERSONATE (alice) ON DBMS TO userImpersonator
To grant (or revoke) the permissions to impersonate a specific user or a subset of users, you can first list them with this query:
GRANT IMPERSONATE (alice, bob) ON DBMS TO userImpersonator
The DBMS DATABASE MANAGEMENT
privileges
The DBMS privileges for database management can be assigned by using Cypher administrative commands. They can be granted, denied and revoked like other privileges.
For more details about the syntax descriptions, see Cypher syntax for administration commands. |
Command | Description |
---|---|
|
Enables the specified roles to create new standard databases and aliases. |
|
Enables the specified roles to delete standard databases and aliases. |
|
Enables the specified roles to modify standard databases and aliases. |
|
Enables the specified roles to modify access to standard databases. |
|
Enables the specified roles to create new composite databases. |
|
Enables the specified roles to delete composite databases. |
|
Enables the specified roles to create and delete composite databases. |
|
Enables the specified roles to create, delete, and modify databases and aliases. |
The ability to create standard databases and aliases can be granted via the CREATE DATABASE
privilege.
See an example:
GRANT CREATE DATABASE ON DBMS TO databaseAdder
The resulting role has privileges that only allow creating standard databases and aliases.
List all privileges for the role databaseAdder
as commands by using the following query:
SHOW ROLE databaseAdder PRIVILEGES AS COMMANDS
command |
---|
|
Rows: 1 |
The ability to create composite databases can be granted via the CREATE COMPOSITE DATABASE
privilege.
See an example:
GRANT CREATE COMPOSITE DATABASE ON DBMS TO compositeDatabaseAdder
The resulting role has privileges that only allow creating composite databases.
List all privileges for the role compositeDatabaseAdder
as commands by using the following query:
SHOW ROLE compositeDatabaseAdder PRIVILEGES AS COMMANDS
command |
---|
|
Rows: 1 |
The ability to delete standard databases and aliases can be granted via the DROP DATABASE
privilege.
See an example:
GRANT DROP DATABASE ON DBMS TO databaseDropper
The resulting role has privileges that only allow deleting standard databases and aliases.
List all privileges for the role databaseDropper
as commands by using the following query:
SHOW ROLE databaseDropper PRIVILEGES AS COMMANDS
command |
---|
|
Rows: 1 |
The ability to delete composite databases can be granted via the DROP COMPOSITE DATABASE
privilege.
See an example:
GRANT DROP COMPOSITE DATABASE ON DBMS TO compositeDatabaseDropper
The resulting role has privileges that only allow deleting composite databases.
List all privileges for the role compositeDatabaseDropper
as commands by using the following query:
SHOW ROLE compositeDatabaseDropper PRIVILEGES AS COMMANDS
command |
---|
|
Rows: 1 |
The ability to modify standard databases and aliases can be granted via the ALTER DATABASE
privilege.
See an example:
GRANT ALTER DATABASE ON DBMS TO databaseModifier
The resulting role has privileges that only allow modifying standard databases and aliases.
List all privileges for the role databaseModifier
as commands by using the following query:
SHOW ROLE databaseModifier PRIVILEGES AS COMMANDS
command |
---|
|
Rows: 1 |
The ability to modify access to standard databases can be granted via the SET DATABASE ACCESS
privilege.
See an example:
GRANT SET DATABASE ACCESS ON DBMS TO accessModifier
The resulting role has privileges that only allow modifying access to standard databases.
List all privileges for the role accessModifier
as commands by using the following query:
SHOW ROLE accessModifier PRIVILEGES AS COMMANDS
command |
---|
|
Rows: 1 |
The ability to create and delete composite databases can be granted via the COMPOSITE DATABASE MANAGEMENT
privilege.
See an example:
GRANT COMPOSITE DATABASE MANAGEMENT ON DBMS TO compositeDatabaseManager
The resulting role has all privileges to manage composite databases.
List all privileges for the role compositeDatabaseManager
as commands by using the following query:
SHOW ROLE compositeDatabaseManager PRIVILEGES AS COMMANDS
command |
---|
|
Rows: 1 |
The ability to create, delete, and modify databases and aliases can be granted via the DATABASE MANAGEMENT
privilege.
See an example:
GRANT DATABASE MANAGEMENT ON DBMS TO databaseManager
The resulting role has all privileges to manage standard and composite databases as well as aliases.
List all privileges for the role databaseManager
as commands by using the following query:
SHOW ROLE databaseManager PRIVILEGES AS COMMANDS
command |
---|
|
Rows: 1 |
The DBMS ALIAS MANAGEMENT
privileges
The DBMS privileges for alias management can be assigned by using Cypher administrative commands and can be applied to both local and remote aliases. They can be granted, denied and revoked like other privileges. It is also possible to manage aliases with database management commands.
For more details about the syntax descriptions, see Cypher syntax for administration commands. |
Command | Description |
---|---|
|
Enables the specified roles to create new aliases. |
|
Enables the specified roles to delete aliases. |
|
Enables the specified roles to modify aliases. |
|
Enables the specified roles to list aliases. |
|
Enables the specified roles to list, create, delete, and modify aliases. |
The ability to create aliases can be granted via the CREATE ALIAS
privilege.
See an example:
GRANT CREATE ALIAS ON DBMS TO aliasAdder
The resulting role has privileges that only allow creating aliases.
List all privileges for the role aliasAdder
as commands by using the following query:
SHOW ROLE aliasAdder PRIVILEGES AS COMMANDS
command |
---|
|
Rows: 1 |
The ability to delete aliases can be granted via the DROP ALIAS
privilege.
See an example:
GRANT DROP ALIAS ON DBMS TO aliasDropper
The resulting role has privileges that only allow deleting aliases.
See all privileges for the role aliasDropper
as commands by using the following query:
SHOW ROLE aliasDropper PRIVILEGES AS COMMANDS
command |
---|
|
Rows: 1 |
The ability to modify aliases can be granted via the ALTER ALIAS
privilege.
See an example:
GRANT ALTER ALIAS ON DBMS TO aliasModifier
The resulting role has privileges that only allow modifying aliases.
List all privileges for the role aliasModifier
as commands by using the following query:
SHOW ROLE aliasModifier PRIVILEGES AS COMMANDS
command |
---|
|
Rows: 1 |
The ability to list aliases can be granted via the SHOW ALIAS
privilege.
See an example:
GRANT SHOW ALIAS ON DBMS TO aliasLister
The resulting role has privileges that only allow modifying aliases.
List all privileges for the role aliasLister
as commands by using the following query:
SHOW ROLE aliasLister PRIVILEGES AS COMMANDS
command |
---|
|
Rows: 1 |
The privileges to list, create, delete, and modify aliases can be granted via the ALIAS MANAGEMENT
privilege.
See an example:
GRANT ALIAS MANAGEMENT ON DBMS TO aliasManager
The resulting role has all privileges to manage aliases.
List all privileges for the role aliasManager
as commands by using the following query:
SHOW ROLE aliasManager PRIVILEGES AS COMMANDS
command |
---|
|
Rows: 1 |
The DBMS SERVER MANAGEMENT
privileges
The DBMS privileges for server management can be assigned using Cypher administrative commands. They can be granted, denied, and revoked like other privileges.
For more details about the syntax descriptions, see Cypher syntax for administration commands. |
Command | Description |
---|---|
|
Enables the specified roles to show, enable, rename, alter, reallocate, deallocate, and drop servers. |
|
Enables the specified roles to show servers. |
The DBMS PRIVILEGE MANAGEMENT
privileges
The DBMS privileges for privilege management can be assigned by using Cypher administrative commands. They can be granted, denied and revoked like other privileges.
For more details about the syntax descriptions, see Cypher syntax for administration commands. |
Command | Description |
---|---|
|
Enables the specified roles to list privileges. |
|
Enables the specified roles to assign privileges using the |
|
Enables the specified roles to remove privileges using the |
|
Enables the specified roles to list, assign, and remove privileges. |
The ability to list privileges can be granted via the SHOW PRIVILEGE
privilege.
A user with this privilege is allowed to execute the SHOW PRIVILEGES
and SHOW ROLE roleName PRIVILEGES
administration commands.
To execute the SHOW USER username PRIVILEGES
administration command, both this privilege and the SHOW USER
privilege are required.
The following query shows an example of how to grant the SHOW PRIVILEGE
privilege:
GRANT SHOW PRIVILEGE ON DBMS TO privilegeShower
The resulting role has privileges that only allow showing privileges.
List all privileges for the role privilegeShower
as commands by using the following query:
SHOW ROLE privilegeShower PRIVILEGES AS COMMANDS
command |
---|
|
Rows: 1 |
Note that no specific privileges are required for showing the current user’s privileges through the In addition, 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.
See an example of how to grant this privilege:
GRANT ASSIGN PRIVILEGE ON DBMS TO privilegeAssigner
The resulting role has privileges that only allow assigning privileges.
List all privileges for the role privilegeAssigner
as commands by using the following query:
SHOW ROLE privilegeAssigner PRIVILEGES AS COMMANDS
command |
---|
|
Rows: 1 |
The ability to remove privileges from roles can be granted via the REMOVE PRIVILEGE
privilege.
A user with this privilege is allowed to execute REVOKE
administration commands.
See an example of how to grant this privilege:
GRANT REMOVE PRIVILEGE ON DBMS TO privilegeRemover
The resulting role has privileges that only allow removing privileges.
List all privileges for the role privilegeRemover
as commands by using the following query:
SHOW ROLE privilegeRemover PRIVILEGES AS COMMANDS
command |
---|
|
Rows: 1 |
The privileges to list, assign, and remove privileges can be granted via the PRIVILEGE MANAGEMENT
privilege.
See an example:
GRANT PRIVILEGE MANAGEMENT ON DBMS TO privilegeManager
The resulting role has all privileges to manage privileges.
List all privileges for the role privilegeManager
as commands by using the following query:
SHOW ROLE privilegeManager PRIVILEGES AS COMMANDS
command |
---|
|
Rows: 1 |
The DBMS EXECUTE
privileges
The DBMS privileges for procedure and user-defined function execution can be assigned by using Cypher administrative commands. They can be granted, denied and revoked like other privileges.
For more details about the syntax descriptions, see Cypher syntax for administration commands. |
Command | Description |
---|---|
|
Enables the specified roles to execute the given procedures. |
|
Enables the specified roles to use elevated privileges when executing the given procedures. |
|
Enables the specified roles to execute procedures annotated with |
|
Enables the specified roles to execute the given user-defined functions. |
|
Enables the specified roles to use elevated privileges when executing the given user-defined functions. |
The EXECUTE PROCEDURE
privilege
The ability to execute a procedure can be granted via the EXECUTE PROCEDURE
privilege.
A role with this privilege is allowed to execute the procedures matched by the name-globbing.
The following query shows an example of how to grant this privilege:
GRANT EXECUTE PROCEDURE db.schema.* ON DBMS TO procedureExecutor
Users with the role procedureExecutor
can then run any procedure in the db.schema
namespace.
The procedure is run using the user’s own privileges.
The resulting role has privileges that only allow executing procedures in the db.schema
namespace.
List all privileges for the role procedureExecutor
as commands by using the following query:
SHOW ROLE procedureExecutor PRIVILEGES AS COMMANDS
command |
---|
|
Rows: 1 |
In order to allow the execution of all but only a few procedures, you can grant EXECUTE PROCEDURES *
and deny the unwanted procedures.
For example, the following queries allow the execution of all procedures, except those starting with dbms.cluster
:
GRANT EXECUTE PROCEDURE * ON DBMS TO deniedProcedureExecutor
DENY EXECUTE PROCEDURE dbms.cluster* ON DBMS TO deniedProcedureExecutor
The resulting role has privileges that only allow executing all procedures except those starting with dbms.cluster
.
List all privileges for the role deniedProcedureExecutor
as commands by using the following query:
SHOW ROLE deniedProcedureExecutor PRIVILEGES AS COMMANDS
command |
---|
|
|
Rows: 2 |
The dbms.cluster.checkConnectivity
, dbms.cluster.cordonServer
, dbms.cluster.protocols
, dbms.cluster.readReplicaToggle
, dbms.cluster.routing.getRoutingTable
, dbms.cluster.secondaryReplicationDisable
, dbms.cluster.setAutomaticallyEnableFreeServers
, and dbms.cluster.uncordonServer
procedures are blocked, as well as any others starting with dbms.cluster
.
The EXECUTE BOOSTED PROCEDURE
privilege
The ability to use elevated privileges when executing a procedure can be granted via the EXECUTE BOOSTED PROCEDURE
privilege.
A user with this privilege will not be restricted to their other privileges when executing the procedures matched by the name-globbing.
The EXECUTE BOOSTED PROCEDURE
privilege only affects the elevation, and not the execution of the procedure.
Therefore, it is needed to grant EXECUTE PROCEDURE
privilege for the procedures as well.
Since Neo4j 5.0, both |
GRANT EXECUTE PROCEDURE * ON DBMS TO boostedProcedureExecutor;
GRANT EXECUTE BOOSTED PROCEDURE db.labels, db.relationshipTypes ON DBMS TO boostedProcedureExecutor
Users with the role boostedProcedureExecutor
can thus run the db.labels
and the db.relationshipTypes
procedures with full privileges, seeing everything in the graph and not just the labels and types that the user has TRAVERSE
privilege on.
Without the EXECUTE PROCEDURE
, no procedures could be executed at all.
The resulting role has privileges that allow executing the procedures db.labels
and db.relationshipTypes
with elevated privileges, and all other procedures with the user’s own privileges:
SHOW ROLE boostedProcedureExecutor PRIVILEGES AS COMMANDS
command |
---|
|
|
|
Rows: 3 |
As with grant, denying EXECUTE BOOSTED PROCEDURE
on its own only affects the elevation and not the execution of the procedure.
This can be seen in the following examples:
EXECUTE PROCEDURE
and deny EXECUTE BOOSTED PROCEDURE
GRANT EXECUTE PROCEDURE * ON DBMS TO deniedBoostedProcedureExecutor1
DENY EXECUTE BOOSTED PROCEDURE db.labels ON DBMS TO deniedBoostedProcedureExecutor1
The resulting role has privileges that allow the execution of all procedures using the user’s own privileges.
It also prevents the db.labels
procedure from being elevated.
Still, the denied EXECUTE BOOSTED PROCEDURE
does not block execution of db.labels
.
To list all privileges for role deniedBoostedProcedureExecutor1
as commands, use the following query:
SHOW ROLE deniedBoostedProcedureExecutor1 PRIVILEGES AS COMMANDS
command |
---|
|
|
Rows: 2 |
EXECUTE BOOSTED PROCEDURE
and deny EXECUTE PROCEDURE
GRANT EXECUTE BOOSTED PROCEDURE * ON DBMS TO deniedBoostedProcedureExecutor2
DENY EXECUTE PROCEDURE db.labels ON DBMS TO deniedBoostedProcedureExecutor2
The resulting role has privileges that allow elevating the privileges for all procedures, but cannot execute any due to missing or denied EXECUTE PROCEDURE
privileges.
List all privileges for the role deniedBoostedProcedureExecutor2
as commands by using the following query:
SHOW ROLE deniedBoostedProcedureExecutor2 PRIVILEGES AS COMMANDS
command |
---|
|
|
Rows: 2 |
EXECUTE BOOSTED PROCEDURE
and deny EXECUTE BOOSTED PROCEDURE
GRANT EXECUTE BOOSTED PROCEDURE * ON DBMS TO deniedBoostedProcedureExecutor3
DENY EXECUTE BOOSTED PROCEDURE db.labels ON DBMS TO deniedBoostedProcedureExecutor3
The resulting role has privileges that allow elevating the privileges for all procedures except db.labels
, however no procedures can be executed due to missing EXECUTE PROCEDURE
privilege.
List all privileges for the role deniedBoostedProcedureExecutor3
as commands by using the following query:
SHOW ROLE deniedBoostedProcedureExecutor3 PRIVILEGES AS COMMANDS
command |
---|
|
|
Rows: 2 |
Assume there is a procedure called myProc
.
This procedure gives the result A
and B
for a user with EXECUTE PROCEDURE
privilege and A
, B
and C
for a user with EXECUTE BOOSTED PROCEDURE
privilege.
Now, adapt the privileges from examples 1 to 3 to be applied to this procedure and show what is returned.
With the privileges from example 1, granted EXECUTE PROCEDURE *
and denied EXECUTE BOOSTED PROCEDURE myProc
, the myProc
procedure returns the result A
and B
.
With the privileges from example 2, granted EXECUTE BOOSTED PROCEDURE *
and denied EXECUTE PROCEDURE myProc
, execution of the myProc
procedure is not allowed.
With the privileges from example 3, granted EXECUTE BOOSTED PROCEDURE *
and denied EXECUTE BOOSTED PROCEDURE myProc
, execution of the myProc
procedure is not allowed.
For comparison, when granted:
-
EXECUTE PROCEDURE myProc
: themyProc
procedure returns the resultA
andB
. -
EXECUTE BOOSTED PROCEDURE myProc
: execution of themyProc
procedure is not allowed. -
EXECUTE PROCEDURE myProc
andEXECUTE BOOSTED PROCEDURE myProc
: themyProc
procedure returns the resultA
,B
, andC
.
The EXECUTE ADMIN PROCEDURE
privilege
The ability to execute admin procedures (annotated with @Admin
) can be granted via the EXECUTE ADMIN PROCEDURES
privilege.
This privilege is equivalent with granting the EXECUTE PROCEDURE
and EXECUTE BOOSTED PROCEDURE
privileges on each of the admin procedures.
Any newly added admin
procedure is automatically included in this privilege.
The following query shows an example of how to grant this privilege:
GRANT EXECUTE ADMIN PROCEDURES ON DBMS TO adminProcedureExecutor
Users with the role adminProcedureExecutor
can then run any admin
procedure with elevated privileges.
The resulting role has privileges that allow the execution of all admin procedures.
List all privileges for the role adminProcedureExecutor
as commands by using the following query:
SHOW ROLE adminProcedureExecutor PRIVILEGES AS COMMANDS
command |
---|
|
Rows: 1 |
In order to compare this with the EXECUTE PROCEDURE
and EXECUTE BOOSTED PROCEDURE
privileges, revisit the myProc
procedure, but this time as an admin
procedure, which will give the result A
, B
and C
when allowed to execute.
By starting with a user only granted the EXECUTE PROCEDURE myProc
or the EXECUTE BOOSTED PROCEDURE myProc
privilege, execution of the myProc
procedure is not allowed.
However, for a user granted the EXECUTE ADMIN PROCEDURES
or both EXECUTE PROCEDURE myProc
and EXECUTE BOOSTED PROCEDURE myProc
, the myProc
procedure returns the result A
, B
and C
.
Any denied EXECUTE
privilege results in the procedure not being allowed to be executed.
In this case, it does not matter whether EXECUTE PROCEDURE
, EXECUTE BOOSTED PROCEDURE
or EXECUTE ADMIN PROCEDURES
is being denied.
The EXECUTE USER DEFINED FUNCTION
privilege
The ability to execute a user-defined function (UDF) can be granted via the EXECUTE USER DEFINED FUNCTION
privilege.
A role with this privilege is allowed to execute the UDFs matched by the name-globbing.
The |
The following query shows an example of how to grant this privilege:
GRANT EXECUTE USER DEFINED FUNCTION apoc.coll.* ON DBMS TO functionExecutor
Or in short form:
GRANT EXECUTE FUNCTION apoc.coll.* ON DBMS TO functionExecutor
Users with the role functionExecutor
can thus run any UDF in the apoc.coll
namespace.
The function here is run using the user’s own privileges.
The resulting role has privileges that only allow executing UDFs in the apoc.coll
namespace.
List all privileges for the role functionExecutor
as commands by using the following query:
SHOW ROLE functionExecutor PRIVILEGES AS COMMANDS
command |
---|
|
Rows: 1 |
To allow the execution of all but a few UDFs, you can grant EXECUTE USER DEFINED FUNCTIONS *
and deny the unwanted functions.
The following queries allow the execution of all UDFs except those starting with apoc.any.prop
:
GRANT EXECUTE USER DEFINED FUNCTIONS * ON DBMS TO deniedFunctionExecutor
DENY EXECUTE USER DEFINED FUNCTION apoc.any.prop* ON DBMS TO deniedFunctionExecutor
Or in short form:
GRANT EXECUTE FUNCTIONS * ON DBMS TO deniedFunctionExecutor
DENY EXECUTE FUNCTION apoc.any.prop* ON DBMS TO deniedFunctionExecutor
The resulting role has privileges that only allow the execution of all procedures except those starting with apoc.any.prop
.
List all privileges for the role deniedFunctionExecutor
as commands by using the following query:
SHOW ROLE deniedFunctionExecutor PRIVILEGES AS COMMANDS
command |
---|
|
|
Rows: 2 |
The apoc.any.property
and apoc.any.properties
are blocked, as well as any other procedures starting with apoc.any.prop
.
The EXECUTE BOOSTED USER DEFINED FUNCTION
privilege
The ability to use elevated privileges when executing a user-defined function (UDF) can be granted via the EXECUTE BOOSTED USER DEFINED FUNCTION
privilege.
A user with this privilege will not be restricted to their other privileges when executing the UDFs matched by the name-globbing.
The EXECUTE BOOSTED USER DEFINED FUNCTION
privilege only affects the elevation and not the execution of the function.
Therefore, it is needed to grant EXECUTE USER DEFINED FUNCTION
privilege for the functions as well.
Since Neo4j 5.0, both |
The |
The following query shows an example of how to grant the EXECUTE BOOSTED USER DEFINED FUNCTION
privilege:
GRANT EXECUTE USER DEFINED FUNCTION * ON DBMS TO boostedFunctionExecutor
GRANT EXECUTE BOOSTED USER DEFINED FUNCTION apoc.any.properties ON DBMS TO boostedFunctionExecutor
Or in short form:
GRANT EXECUTE FUNCTION * ON DBMS TO boostedFunctionExecutor
GRANT EXECUTE BOOSTED FUNCTION apoc.any.properties ON DBMS TO boostedFunctionExecutor
Users with the role boostedFunctionExecutor
can thus run apoc.any.properties
with full privileges and see every property on the node/relationship, not just the properties that the user has READ
privilege on.
Without the EXECUTE USER DEFINED FUNCTION
no UDFs could be executed at all.
The resulting role has privileges that allow executing the UDF apoc.any.properties
with elevated privileges, and all other UDFs with the users' own privileges.
List all privileges for the role boostedFunctionExecutor
as commands by using the following query:
SHOW ROLE boostedFunctionExecutor PRIVILEGES AS COMMANDS
command |
---|
|
|
Rows: 2 |
The DBMS SETTING
privileges
The ability to show configuration settings can be granted via the SHOW SETTING
privilege.
A role with this privilege is allowed to query the configuration settings matched by the name-globbing.
For more details about the syntax descriptions, see Cypher syntax for administration commands. |
Command | Description |
---|---|
|
Enables the specified roles to query given configuration settings. |
The following query shows an example of how to grant this privilege:
GRANT SHOW SETTING server.bolt.* ON DBMS TO configurationViewer
Users with the role configurationViewer
can then query any setting in the server.bolt
namespace.
The updated role configurationViewer
has privileges that only allow querying settings in the server.bolt
namespace.
List all privileges for the role configurationViewer
as commands by using the following query:
SHOW ROLE configurationViewer PRIVILEGES AS COMMANDS
command |
---|
|
Rows: 1 |
To deny a specific setting from a role, first grant SHOW SETTINGS *
, and then deny the unwanted setting.
For example, the following queries allow the querying of all settings, except those starting with dbms.security
:
GRANT SHOW SETTINGS * ON DBMS TO deniedConfigurationViewer
DENY SHOW SETTING dbms.security* ON DBMS TO deniedConfigurationViewer
The resulting role has privileges that allow querying all settings except those starting with dbms.security
.
List all privileges for the role deniedConfigurationViewer
as commands by using the following query:
SHOW ROLE deniedConfigurationViewer PRIVILEGES AS COMMANDS
command |
---|
|
|
Rows: 2 |
As the query result shows, access to any setting starting with dbms.security
are blocked, but the rest can still be queried.
Granting ALL DBMS PRIVILEGES
The right to perform the following privileges can be achieved with a single command:
-
Create, drop, assign, remove, and show roles.
-
Create, alter, drop, show, and impersonate users.
-
Create, alter, and drop databases and aliases.
-
Enable, alter, rename, reallocate, deallocate, and drop servers
-
Show, assign, and remove privileges.
-
Execute all procedures with elevated privileges.
-
Execute all user-defined functions with elevated privileges.
-
Show all configuration settings.
For more details about the syntax descriptions, see Cypher syntax for administration commands. |
GRANT [IMMUTABLE] ALL [[DBMS] PRIVILEGES]
ON DBMS
TO role[, ...]
For example, to grant the role dbmsManager
the abilities above, use the following query:
GRANT ALL DBMS PRIVILEGES ON DBMS TO dbmsManager
The privileges granted can be seen using the SHOW PRIVILEGES
command:
SHOW ROLE dbmsManager PRIVILEGES AS COMMANDS
command |
---|
|
Rows: 1 |
Name-globbing for procedures, user-defined functions, and settings
The name-globbing for procedures, user-defined functions, and setting names is a simplified version of globbing for filename expansions.
It only allows two wildcard characters: *
and ?
, which are used for multiple and single-character matches.
In this case, *
means 0 or more characters, and ?
matches exactly one character.
The name-globbing is subject to the Cypher Manual → Naming rules and recommendations, with the exception that it may include dots, stars, and question marks without the need for escaping using backticks. Each part of the name-globbing separated by dots may be individually quoted.
For example, |
Given the following list of procedures:
-
mine.public.exampleProcedure
-
mine.public.exampleProcedure1
-
mine.public.exampleProcedure2
-
mine.public.with#Special§Characters
-
mine.private.exampleProcedure
-
mine.private.exampleProcedure1
-
mine.private.exampleProcedure2
-
mine.private.with#Special§Characters
-
your.exampleProcedure
The following examples demonstrate how name-globbing patterns can be used in controlling access to procedures. Note that the same rules apply to user-defined functions and settings.
GRANT EXECUTE PROCEDURE * ON DBMS TO globbing1
Users with the role globbing1
can run all the procedures.
GRANT EXECUTE PROCEDURE mine.*.exampleProcedure ON DBMS TO globbing2
Users with the role globbing2
can run procedures mine.public.exampleProcedure
and mine.private.exampleProcedure
, but no other procedures.
GRANT EXECUTE PROCEDURE mine.*.exampleProcedure? ON DBMS TO globbing3
Users with the role globbing3
can run procedures mine.public.exampleProcedure1
, mine.private.exampleProcedure1
, and mine.private.exampleProcedure2
, but no other procedures.
GRANT EXECUTE PROCEDURE *.exampleProcedure ON DBMS TO globbing4
Users with the role globbing4
can run procedures your.exampleProcedure
, mine.public.exampleProcedure
, and mine.private.exampleProcedure
, but no other procedures.
GRANT EXECUTE PROCEDURE mine.public.exampleProcedure* ON DBMS TO globbing5
Users with the role globbing5
can run procedures mine.public.exampleProcedure
, mine.public.exampleProcedure1
and mine.public.exampleProcedure42
, but no other procedures.
GRANT EXECUTE PROCEDURE `mine.public.with#*§Characters`, mine.private.`with#Spec???§Characters` ON DBMS TO globbing6
Users with the role globbing6
can run procedures mine.public.with#Special§Characters
, and mine.private.with#Special§Characters
, but no other procedures.
The name-globbing may be fully or partially quoted.
Both |