From 951b91f1021463674ff6053b1cc4a24cdd865152 Mon Sep 17 00:00:00 2001 From: lidiazuin Date: Mon, 25 Jul 2022 15:16:10 +0200 Subject: [PATCH 1/5] editorial review of access control --- .../pages/access-control/built-in-roles.adoc | 147 ++- .../database-administration.adoc | 856 ++++------------- .../access-control/dbms-administration.adoc | 903 +++++++++--------- modules/ROOT/pages/access-control/index.adoc | 92 +- .../pages/access-control/limitations.adoc | 265 +++-- .../access-control/manage-privileges.adoc | 393 +++----- .../pages/access-control/manage-roles.adoc | 269 ++---- .../pages/access-control/manage-users.adoc | 318 +++--- .../access-control/privileges-reads.adoc | 155 +-- .../access-control/privileges-writes.adoc | 296 +++--- 10 files changed, 1462 insertions(+), 2232 deletions(-) diff --git a/modules/ROOT/pages/access-control/built-in-roles.adoc b/modules/ROOT/pages/access-control/built-in-roles.adoc index 6b4728b27..294da2c57 100644 --- a/modules/ROOT/pages/access-control/built-in-roles.adoc +++ b/modules/ROOT/pages/access-control/built-in-roles.adoc @@ -1,5 +1,3 @@ -:description: The default privileges of the built-in roles in Neo4j and how to recreate them if needed. - [role=enterprise-edition] [[access-control-built-in-roles]] = Built-in roles and privileges @@ -12,30 +10,29 @@ This section explains the default privileges of the built-in roles in Neo4j and All of the commands described in this chapter require that the user executing the commands has the rights to do so. The privileges listed in the following sections are the default set of privileges for each built-in role: -* xref::access-control/built-in-roles.adoc#access-control-built-in-roles-public[The `PUBLIC` role] -* xref::access-control/built-in-roles.adoc#access-control-built-in-roles-reader[The `reader` role] -* xref::access-control/built-in-roles.adoc#access-control-built-in-roles-editor[The `editor` role] -* xref::access-control/built-in-roles.adoc#access-control-built-in-roles-publisher[The `publisher` role] -* xref::access-control/built-in-roles.adoc#access-control-built-in-roles-architect[The `architect` role] -* xref::access-control/built-in-roles.adoc#access-control-built-in-roles-admin[The `admin` role] - +* <> +* <> +* <> +* <> +* <> +* <> [[access-control-built-in-roles-public]] == The `PUBLIC` role All users are granted the `PUBLIC` role, and it can not be revoked or dropped. -By default, it gives access to the default database and allows executing all procedures and user defined functions. +By default, it gives access to the default database and allows executing all procedures and user-defined functions. [IMPORTANT] ==== -The `PUBLIC` role cannot be dropped or revoked from any user, but the specific privileges for the role may be modified. +The `PUBLIC` role cannot be dropped or revoked from any user, but the specific privileges for the role can be modified. In contrast to the `PUBLIC` role, the other built-in roles can be granted, revoked, dropped, and re-created. ==== [[access-control-built-in-roles-public-list]] === Listing `PUBLIC` role privileges -[source, cypher, role=noplay, indent=0] +[source, cypher, role=noplay] ---- SHOW ROLE PUBLIC PRIVILEGES AS COMMANDS ---- @@ -56,20 +53,21 @@ a|Rows: 3 The `PUBLIC` role can not be dropped and thus there is no need to recreate the role itself. To restore the role to its original capabilities, two steps are needed. + First, all `GRANT` or `DENY` privileges on this role should be revoked (see output of `SHOW ROLE PUBLIC PRIVILEGES AS REVOKE COMMANDS` on what to revoke). -Secondly, the following queries must be run: +Secondly, run these queries: -[source, cypher, role=noplay, indent=0] +[source, cypher, role=noplay] ---- GRANT ACCESS ON HOME DATABASE TO PUBLIC ---- -[source, cypher, role=noplay, indent=0] +[source, cypher, role=noplay] ---- GRANT EXECUTE PROCEDURES * ON DBMS TO PUBLIC ---- -[source, cypher, role=noplay, indent=0] +[source, cypher, role=noplay] ---- GRANT EXECUTE USER DEFINED FUNCTIONS * ON DBMS TO PUBLIC ---- @@ -86,7 +84,7 @@ The `reader` role can perform read-only queries on all graphs except for the `sy [[access-control-built-in-roles-reader-list]] === Listing `reader` role privileges -[source, cypher, role=noplay, indent=0] +[source, cypher, role=noplay] ---- SHOW ROLE reader PRIVILEGES AS COMMANDS ---- @@ -106,20 +104,20 @@ a|Rows: 3 === Recreating the `reader` role To restore the role to its original capabilities two steps are needed. -First, if not already done, execute `DROP ROLE reader`. -Secondly, the following queries must be run: +First, execute `DROP ROLE reader`. +Secondly, run these queries: -[source, cypher, role=noplay, indent=0] +[source, cypher, role=noplay] ---- CREATE ROLE reader ---- -[source, cypher, role=noplay, indent=0] +[source, cypher, role=noplay] ---- GRANT ACCESS ON DATABASE * TO reader ---- -[source, cypher, role=noplay, indent=0] +[source, cypher, role=noplay] ---- GRANT MATCH {*} ON GRAPH * TO reader ---- @@ -130,12 +128,12 @@ The resulting `reader` role now has the same privileges as the original built-in [[access-control-built-in-roles-editor]] == The `editor` role -The `editor` role can perform read and write operations on all graphs except for the `system` database, but can not make new labels, property keys or relationship types. +The `editor` role can perform read and write operations on all graphs except for the `system` database, but it cannot create new labels, property keys or relationship types. [[access-control-built-in-roles-editor-list]] === Listing `editor` role privileges -[source, cypher, role=noplay, indent=0] +[source, cypher, role=noplay] ---- SHOW ROLE editor PRIVILEGES AS COMMANDS ---- @@ -156,25 +154,25 @@ a|Rows: 4 === Recreating the `editor` role To restore the role to its original capabilities two steps are needed. -First, if not already done, execute `DROP ROLE editor`. -Secondly, the following queries must be run: +First, execute `DROP ROLE editor`. +Secondly, run these queries: -[source, cypher, role=noplay, indent=0] +[source, cypher, role=noplay] ---- CREATE ROLE editor ---- -[source, cypher, role=noplay, indent=0] +[source, cypher, role=noplay] ---- GRANT ACCESS ON DATABASE * TO editor ---- -[source, cypher, role=noplay, indent=0] +[source, cypher, role=noplay] ---- GRANT MATCH {*} ON GRAPH * TO editor ---- -[source, cypher, role=noplay, indent=0] +[source, cypher, role=noplay] ---- GRANT WRITE ON GRAPH * TO editor ---- @@ -185,13 +183,13 @@ The resulting `editor` role now has the same privileges as the original built-in [[access-control-built-in-roles-publisher]] == The `publisher` role -The `publisher` role can do the same as xref::access-control/built-in-roles.adoc#access-control-built-in-roles-editor[`editor`], but can also create new labels, property keys and relationship types. +The `publisher` role can do the same as <>, as well as create new labels, property keys and relationship types. [[access-control-built-in-roles-publisher-list]] === Listing `publisher` role privileges -[source, cypher, role=noplay, indent=0] +[source, cypher, role=noplay] ---- SHOW ROLE publisher PRIVILEGES AS COMMANDS ---- @@ -213,30 +211,30 @@ a|Rows: 5 === Recreating the `publisher` role To restore the role to its original capabilities two steps are needed. -First, if not already done, execute `DROP ROLE publisher`. -Secondly, the following queries must be run: +First, execute `DROP ROLE publisher`. +Secondly, run these queries: -[source, cypher, role=noplay, indent=0] +[source, cypher, role=noplay] ---- CREATE ROLE publisher ---- -[source, cypher, role=noplay, indent=0] +[source, cypher, role=noplay] ---- GRANT ACCESS ON DATABASE * TO publisher ---- -[source, cypher, role=noplay, indent=0] +[source, cypher, role=noplay] ---- GRANT MATCH {*} ON GRAPH * TO publisher ---- -[source, cypher, role=noplay, indent=0] +[source, cypher, role=noplay] ---- GRANT WRITE ON GRAPH * TO publisher ---- -[source, cypher, role=noplay, indent=0] +[source, cypher, role=noplay] ---- GRANT NAME MANAGEMENT ON DATABASE * TO publisher ---- @@ -247,13 +245,13 @@ The resulting `publisher` role now has the same privileges as the original built [[access-control-built-in-roles-architect]] == The `architect` role -The `architect` role can do the same as the xref::access-control/built-in-roles.adoc#access-control-built-in-roles-publisher[`publisher`], as well as create and manage indexes and constraints. +The `architect` role can do the same as the <>, as well as create and manage indexes and constraints. [[access-control-built-in-roles-architect-list]] === Listing `architect` role privileges -[source, cypher, role=noplay, indent=0] +[source, cypher, role=noplay] ---- SHOW ROLE architect PRIVILEGES AS COMMANDS ---- @@ -277,35 +275,35 @@ a|Rows: 7 === Recreating the `architect` role To restore the role to its original capabilities two steps are needed. -First, if not already done, execute `DROP ROLE architect`. -Secondly, the following queries must be run: +First, execute `DROP ROLE architect`. +Secondly, run these queries: -[source, cypher, role=noplay, indent=0] +[source, cypher, role=noplay] ---- GRANT ACCESS ON DATABASE * TO architect ---- -[source, cypher, role=noplay, indent=0] +[source, cypher, role=noplay] ---- GRANT MATCH {*} ON GRAPH * TO architect ---- -[source, cypher, role=noplay, indent=0] +[source, cypher, role=noplay] ---- GRANT WRITE ON GRAPH * TO architect ---- -[source, cypher, role=noplay, indent=0] +[source, cypher, role=noplay] ---- GRANT NAME MANAGEMENT ON DATABASE * TO architect ---- -[source, cypher, role=noplay, indent=0] +[source, cypher, role=noplay] ---- GRANT INDEX MANAGEMENT ON DATABASE * TO architect ---- -[source, cypher, role=noplay, indent=0] +[source, cypher, role=noplay] ---- GRANT CONSTRAINT MANAGEMENT ON DATABASE * TO architect ---- @@ -316,30 +314,30 @@ The resulting `architect` role now has the same privileges as the original built [[access-control-built-in-roles-admin]] == The `admin` role -The `admin` role can do the same as the xref::access-control/built-in-roles.adoc#access-control-built-in-roles-architect[`architect`], as well as manage databases, aliases, users, roles and privileges. +The `admin` role can do the same as the <>, as well as manage databases, aliases, users, roles and privileges. The `admin` role has the ability to perform administrative tasks. These include the rights to perform the following classes of tasks: -* Manage xref::access-control/database-administration.adoc[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 xref::indexes-for-search-performance.adoc[indexes] and xref::constraints/index.adoc[constraints] -** Allow the creation of labels, relationship types or property names +* Manage <> to control the rights to perform actions on specific databases: +** Manage access to a database and the right to start and stop a database. +** Manage <> and <>. +** Allow the creation of labels, relationship types or property names. ** Manage transactions -* Manage xref::access-control/dbms-administration.adoc[DBMS security] for controlling the rights to perform actions on the entire system: -** Manage xref::databases.adoc[multiple databases] -** Manage xref::access-control/manage-users.adoc[users] and xref::access-control/manage-roles.adoc[roles] -** Change configuration parameters -** Manage sub-graph privileges -** Manage procedure security +* Manage <> to control the rights to perform actions on the entire system: +** Manage <>. +** Manage <> and <>. +** Change configuration parameters. +** Manage sub-graph privileges. +** Manage procedure security. -These rights are conferred using privileges that can be managed using xref::access-control/manage-privileges.adoc#access-control-graph-privileges[`GRANT`, `DENY`, and `REVOKE` commands]. +These rights are conferred using privileges that can be managed through the <>. [[access-control-built-in-roles-admin-list]] === Listing `admin` role privileges -[source, cypher, role=noplay, indent=0] +[source, cypher, role=noplay] ---- SHOW ROLE admin PRIVILEGES AS COMMANDS ---- @@ -362,57 +360,56 @@ SHOW ROLE admin PRIVILEGES AS COMMANDS a|Rows: 11 |=== -If the built-in admin role has been altered or dropped, and needs to be restored to its original state, see xref:4.4@operations-manual:ROOT:configuration/password-and-user-recovery/index.adoc[Operations Manual -> Password and user recovery]. +If the built-in `admin` role has been altered or dropped, and needs to be restored to its original state, see < Password and user recovery>>. [[access-control-built-in-roles-admin-recreate]] === Recreating the `admin` role To restore the role to its original capabilities two steps are needed. -First, if not already done, execute `DROP ROLE admin`. -Secondly, the following queries must be run in order to set up the privileges: +First, execute `DROP ROLE admin`. +Secondly, run these queries: -[source, cypher, role=noplay, indent=0] +[source, cypher, role=noplay] ---- CREATE ROLE admin ---- -[source, cypher, role=noplay, indent=0] +[source, cypher, role=noplay] ---- GRANT ALL DBMS PRIVILEGES ON DBMS TO admin ---- -[source, cypher, role=noplay, indent=0] +[source, cypher, role=noplay] ---- GRANT TRANSACTION MANAGEMENT ON DATABASE * TO admin ---- -[source, cypher, role=noplay, indent=0] +[source, cypher, role=noplay] ---- GRANT START ON DATABASE * TO admin ---- -[source, cypher, role=noplay, indent=0] +[source, cypher, role=noplay] ---- GRANT STOP ON DATABASE * TO admin ---- -[source, cypher, role=noplay, indent=0] +[source, cypher, role=noplay] ---- GRANT MATCH {*} ON GRAPH * TO admin ---- -[source, cypher, role=noplay, indent=0] +[source, cypher, role=noplay] ---- GRANT WRITE ON GRAPH * TO admin ---- -[source, cypher, role=noplay, indent=0] +[source, cypher, role=noplay] ---- GRANT ALL ON DATABASE * TO admin ---- The resulting `admin` role now has the same privileges as the original built-in `admin` role. -Additional information about restoring the admin role can be found in the xref:4.4@operations-manual:ROOT:configuration/password-and-user-recovery/index.adoc#recover-admin-role[Operations Manual -> Recover the admin role]. - +Additional information about restoring the `admin` role can be found at < Recover the admin role>>. diff --git a/modules/ROOT/pages/access-control/database-administration.adoc b/modules/ROOT/pages/access-control/database-administration.adoc index 06a539b9e..30054dcb3 100644 --- a/modules/ROOT/pages/access-control/database-administration.adoc +++ b/modules/ROOT/pages/access-control/database-administration.adoc @@ -1,5 +1,3 @@ -:description: How to use Cypher to manage Neo4j database administrative privileges. - [role=enterprise-edition] [[access-control-database-administration]] = Database administration @@ -9,13 +7,13 @@ This section explains how to use Cypher to manage Neo4j database administrative privileges. -- -The administrators can use the following Cypher commands to manage Neo4j database administrative rights. +Administrators can use the following Cypher commands to manage Neo4j database administrative rights. The components of the database privilege commands are: -* the command: +* the commands: ** `GRANT` – gives privileges to roles. ** `DENY` – denies privileges to roles. -** `REVOKE` – removes granted or denied privilege from roles. +** `REVOKE` – removes granted or denied privileges from roles. * _database-privilege_ @@ -31,8 +29,8 @@ The components of the database privilege commands are: ** `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. +** `CREATE NEW [RELATIONSHIP] TYPE` - allows relationship types to be created, so that relationships can be assigned to them. +** `CREATE NEW [PROPERTY] NAME` - allows property names to be created, so that nodes and relationships can have properties assigned with these names. ** `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 or remote database alias. ** `SHOW TRANSACTION` - allows listing transactions and queries for the specified users on the specified database. @@ -44,7 +42,7 @@ The components of the database privilege commands are: + [NOTE] ==== -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. +If you delete a database and create a new one with the same name, the new one will NOT have the same privileges previously assigned to the deleted one. ==== ** The _name_ component can be `+*+`, which means all databases. Databases created after this command execution will also be associated with these privileges. @@ -56,453 +54,173 @@ This can be quite powerful as it allows permissions to be switched from one data * _role[, ...]_ ** The role or roles to associate the privilege with, comma-separated. - -.General grant +ON DATABASE+ privilege syntax -[cols="<15s,<85"] -|=== - -| Command -m| +GRANT ... ON ... TO ...+ - -| Syntax -a| -[source, syntax, role="noheader", indent=0] ----- -GRANT database-privilege ON { HOME DATABASE \| DATABASE[S] { * \| name[, ...] } } TO role[, ...] ----- - -| Description -| Grant a privilege to one or multiple roles. - -|=== - - -.General deny +ON DATABASE+ privilege syntax -[cols="<15s,<85"] -|=== - -| Command -m| +DENY ... ON ... TO ...+ - -| Syntax -a| -[source, syntax, role="noheader", indent=0] ----- -DENY database-privilege ON { HOME DATABASE \| DATABASE[S] { * \| name[, ...] } } TO role[, ...] ----- - -| Description -| Deny a privilege to one or multiple roles. - -|=== - - -.General revoke +ON DATABASE+ privilege syntax -[cols="<15s,<85"] -|=== - -| Command -m| +REVOKE GRANT ... ON ... FROM ...+ - -| Syntax -a| -[source, syntax, role="noheader", indent=0] ----- -REVOKE GRANT database-privilege ON { HOME DATABASE \| DATABASE[S] { * \| name[, ...] } } FROM role[, ...] ----- - -| Description -| Revoke a granted privilege from one or multiple roles. - -|=== - - -.General revoke +ON DATABASE+ privilege syntax -[cols="<15s,<85"] -|=== - -| Command -m| +REVOKE DENY ... ON ... FROM ...+ - -| Syntax -a| -[source, syntax, role="noheader", indent=0] ----- -REVOKE DENY database-privilege ON { HOME DATABASE \| DATABASE[S] { * \| name[, ...] } } FROM role[, ...] ----- - -| Description -| Revoke a denied privilege from one or multiple roles. - +.General database privilege command syntax +[options="header", width="100%", cols="3a,2"] |=== +| Command | Description +| [source, cypher, role=noplay] +GRANT database-privilege ON {HOME DATABASE \| DATABASE[S] {* \| name[, ...]}} TO role[, ...] +| Grants a privilege to one or multiple roles. -.General revoke +ON DATABASE+ privilege syntax -[cols="<15s,<85"] -|=== - -| Command -m| +REVOKE ... ON ... FROM ...+ +| [source, cypher, role=noplay] +DENY database-privilege ON {HOME DATABASE \| DATABASE[S] {* \| name[, ...]}} TO role[, ...] +| Denies a privilege to one or multiple roles. -| Syntax -a| -[source, syntax, role="noheader", indent=0] ----- -REVOKE database-privilege ON { HOME DATABASE \| DATABASE[S] { * \| name[, ...] } } FROM role[, ...] ----- +| [source, cypher, role=noplay] +REVOKE GRANT database-privilege ON {HOME DATABASE \| DATABASE[S] {* \| name[, ...]}} FROM role[, ...] +| Revokes a granted privilege from one or multiple roles. -| Description -| Revoke a granted or denied privilege from one or multiple roles. +| [source, cypher, role=noplay] +REVOKE DENY database-privilege ON {HOME DATABASE \| DATABASE[S] {* \| name[, ...]}} FROM role[, ...] +| Revokes a denied privilege from one or multiple roles. +| [source, cypher, role=noplay] +REVOKE database-privilege ON {HOME DATABASE \| DATABASE[S] {* \| name[, ...]}} FROM role[, ...] +| Revokes a granted or denied privilege from one or multiple roles. |=== - [NOTE] ==== -`DENY` does NOT erase a granted privilege; they both exist. +`DENY` does NOT erase a granted privilege. Use `REVOKE` if you want to remove a privilege. ==== The hierarchy between the different database privileges is shown in the image below. -image::privileges_hierarchy_database.png[title="Database privileges hierarchy"] +image::privilege-hierarchy-database.png[title="Database privileges hierarchy"] - - - -.Database privilege syntax -[cols="<15s,<85"] +.Database privilege command syntax +[options="header", width="100%", cols="3a,2a"] |=== +| Command | Description -| Command -m| +GRANT ACCESS+ - -| Syntax -a| -[source, syntax, role="noheader", indent=0] ----- +| [source, cypher, role=noplay] GRANT ACCESS - ON { HOME DATABASE \| DATABASE[S] { * \| name[, ...] } } - TO role[, ...] ----- - -| Description -a| -Grant the specified roles the privilege to access: - -* The home database. -* Specific database(s) or remote database alias(es). -* All databases and remote database aliases. - -|=== - - -.Database privilege syntax -[cols="<15s,<85"] -|=== - -| Command -m| +GRANT { START \| STOP }+ - -| Syntax -a| -[source, syntax, role="noheader", indent=0] ----- -GRANT { START \| STOP } - ON { HOME DATABASE \| DATABASE[S] {* \| name[, ...] } } - TO role[, ...] ----- - -| Description -| Grant the specified roles the privilege to start or stop the home database, specific database(s), or all databases. - -|=== - - -.Database privilege syntax -[cols="<15s,<85"] -|=== - -| Command -m| +GRANT { CREATE \| DROP \| SHOW } INDEX+ - -| Syntax -a| -[source, syntax, role="noheader", indent=0] ----- -GRANT { CREATE \| DROP \| SHOW } INDEX[ES] - ON { HOME DATABASE \| DATABASE[S] { * \| name[, ...] } } - TO role[, ...] ----- - -| Description -| Grant the specified roles the privilege to create, delete, or show indexes on the home database, specific database(s), or all databases. - -|=== - - -.Database privilege syntax -[cols="<15s,<85"] -|=== - -| Command -m| +GRANT INDEX+ - -| Syntax -a| -[source, syntax, role="noheader", indent=0] ----- + ON {HOME DATABASE \| DATABASE[S] {* \| name[, ...]}} + TO role[, ...] +| Grants the specified roles the privilege to access: + +* the home database +* specific database(s) or remote database alias(es) +* all databases and remote database aliases + +| [source, cypher, role=noplay] +GRANT {START \| STOP} + ON {HOME DATABASE \| DATABASE[S] {* \| name[, ...]}} + TO role[, ...] +| Grants the specified roles the privilege to start and stop the home database, specific database(s), or all databases. + +| [source, cypher, role=noplay] +GRANT {CREATE \| DROP \| SHOW} INDEX[ES] + ON {HOME DATABASE \| DATABASE[S] {* \| name[, ...]}} + TO role[, ...] +| Grants the specified roles the privilege to create, delete, or show indexes on the home database, specific database(s), or all databases. + +| [source, cypher, role=noplay] GRANT INDEX[ES] [MANAGEMENT] - ON { HOME DATABASE \| DATABASE[S] { * \| name[, ...] } } - TO role[, ...] ----- - -| Description -| Grant the specified roles the privilege to manage indexes on the home database, specific database(s), or all databases. - -|=== - - -.Database privilege syntax -[cols="<15s,<85"] -|=== - -| Command -m| +GRANT { CREATE \| DROP \| SHOW } CONSTRAINT+ - -| Syntax -a| -[source, syntax, role="noheader", indent=0] ----- -GRANT { CREATE \| DROP \| SHOW } CONSTRAINT[S] - ON { HOME DATABASE \| DATABASE[S] { * \| name[, ...] } } - TO role[, ...] ----- - -| Description -| Grant the specified roles the privilege to create, delete, or show constraints on the home database, specific database(s), or all databases. - -|=== - - -.Database privilege syntax -[cols="<15s,<85"] -|=== + ON {HOME DATABASE \| DATABASE[S] {* \| name[, ...]}} + TO role[, ...] +| Grants the specified roles the privilege to manage indexes on the home database, specific database(s), or all databases. -| Command -m| +GRANT CONSTRAINT+ +| [source, cypher, role=noplay] +GRANT {CREATE \| DROP \| SHOW} CONSTRAINT[S] + ON {HOME DATABASE \| DATABASE[S] {* \| name[, ...]}} + TO role[, ...] +| Grants the specified roles the privilege to create, delete, or show constraints on the home database, specific database(s), or all databases. -| Syntax -a| -[source, syntax, role="noheader", indent=0] ----- +| [source, cypher, role=noplay] GRANT CONSTRAINT[S] [MANAGEMENT] - ON { HOME DATABASE \| DATABASE[S] { * \| name[, ...] } } - TO role[, ...] ----- - -| Description -| Grant the specified roles the privilege to manage constraints on the home database, specific database(s), or all databases. - -|=== - - -.Database privilege syntax -[cols="<15s,<85"] -|=== + ON {HOME DATABASE \| DATABASE[S] {* \| name[, ...]}} + TO role[, ...] +| Grants the specified roles the privilege to manage constraints on the home database, specific database(s), or all databases. -| Command -m| +GRANT CREATE NEW LABEL+ - -| Syntax -a| -[source, syntax, role="noheader", indent=0] ----- +| [source, cypher, role=noplay] GRANT CREATE NEW [NODE] LABEL[S] - ON { HOME DATABASE \| DATABASE[S] { * \| name[, ...] } } - TO role[, ...] ----- - -| Description -| Grant the specified roles the privilege to create new node labels in the home database, specific database(s), or all databases. - -|=== + ON {HOME DATABASE \| DATABASE[S] {* \| name[, ...]}} + TO role[, ...] +| Grants the specified roles the privilege to create new node labels in the home database, specific database(s), or all databases. - -.Database privilege syntax -[cols="<15s,<85"] -|=== - -| Command -m| +GRANT CREATE NEW TYPE+ - -| Syntax -a| -[source, syntax, role="noheader", indent=0] ----- +| [source, cypher, role=noplay] GRANT CREATE NEW [RELATIONSHIP] TYPE[S] - ON { HOME DATABASE \| DATABASE[S] { * \| name[, ...] } } - TO role[, ...] ----- - -| Description -| Grant the specified roles the privilege to create new relationship types in the home database, specific database(s), or all databases. - -|=== - + ON {HOME DATABASE \| DATABASE[S] {* \| name[, ...]}} + TO role[, ...] +| Grants the specified roles the privilege to create new relationships types in the home database, specific database(s), or all databases. -.Database privilege syntax -[cols="<15s,<85"] -|=== - -| Command -m| +GRANT CREATE NEW NAME+ - -| Syntax -a| -[source, syntax, role="noheader", indent=0] ----- +| [source, cypher, role=noplay] GRANT CREATE NEW [PROPERTY] NAME[S] - ON { HOME DATABASE \| DATABASE[S] { * \| name[, ...] } } - TO role[, ...] ----- - -| Description -| Grant the specified roles the privilege to create new property names in the home database, specific database(s), or all databases. + ON {HOME DATABASE \| DATABASE[S] {* \| name[, ...]}} + TO role[, ...] +| Grants the specified roles the privilege to create new property names in the home database, specific database(s), or all databases. -|=== - - -.Database privilege syntax -[cols="<15s,<85"] -|=== - -| Command -m| +GRANT NAME+ - -| Syntax -a| -[source, syntax, role="noheader", indent=0] ----- +| [source, cypher, role=noplay] GRANT NAME [MANAGEMENT] - ON { HOME DATABASE \| DATABASE[S] { * \| name[, ...] } } - TO role[, ...] ----- - -| Description -| Grant the specified roles the privilege to manage new labels, relationship types, and property names in the home database, specific database(s), or all databases. + ON {HOME DATABASE \| DATABASE[S] {* \| name[, ...]}} + TO role[, ...] +| Grants the specified roles the privilege to manage new labels, relationship types, and property names in the home database, specific database(s), or all databases. -|=== - - -.Database privilege syntax -[cols="<15s,<85"] -|=== - -| Command -m| +GRANT ALL+ - -| Syntax -a| -[source, syntax, role="noheader", indent=0] ----- +| [source, cypher, role=noplay] GRANT ALL [[DATABASE] PRIVILEGES] - ON { HOME DATABASE \| DATABASE[S] { * \| name[, ...] } } - TO role[, ...] ----- - -| Description -| Grant the specified roles all privileges for the home, a specific, or all databases and remote database aliases. - -|=== - - -.Database privilege syntax -[cols="<15s,<85"] -|=== - -| Command -m| +GRANT { SHOW \| TERMINATE } TRANSACTION+ - -| Syntax -a| -[source, syntax, role="noheader", indent=0] ----- -GRANT { SHOW \| TERMINATE } TRANSACTION[S] [( { * \| user[, ...] } )] - ON { HOME DATABASE \| DATABASE[S] { * \| name[, ...] } } - TO role[, ...] ----- - -| Description -| Grant the specified roles the privilege to list and end the transactions and queries of all users or a particular user(s) in the home database, specific database(s), or all databases. - -|=== - - -.Database privilege syntax -[cols="<15s,<85"] -|=== - -| Command -m| +GRANT TRANSACTION+ + ON {HOME DATABASE \| DATABASE[S] {* \| name[, ...]}} + TO role[, ...] +| Grants the specified roles all privileges for the home, a specific, or all databases and remote database aliases. -| Syntax -a| -[source, syntax, role="noheader", indent=0] ----- -GRANT TRANSACTION [MANAGEMENT] [( { * \| user[, ...] } )] - ON { HOME DATABASE \| DATABASE[S] { * \| name[, ...] } } - TO role[, ...] ----- +| [source, cypher, role=noplay] +GRANT {SHOW \| TERMINATE} TRANSACTION[S] [( {* \| user[, ...]} )] +ON {HOME DATABASE \| DATABASE[S] {* \| name[, ...]}} +TO role[, ...] +| Grants the specified roles the privilege to list and end the transactions and queries of all users or a particular user(s) in the home database, specific database(s), or all databases. -| Description -| Grant the specified roles the privilege to manage the transactions and queries of all users or a particular user(s) in the home database, specific database(s), or all databases. +| [source, cypher, role=noplay] +GRANT TRANSACTION [MANAGEMENT] [( {* \| user[, ...]} )] +ON {HOME DATABASE \| DATABASE[S] {* \| name[, ...]}} +TO role[, ...] +| Grants the specified roles the privilege to manage the transactions and queries of all users or a particular user(s) in the home database, specific database(s), or all databases. |=== - -image::privileges_grant_and_deny_syntax_database_privileges.png[title="Syntax of GRANT and DENY Database Privileges"] +image::grant-privileges-database.png[title="Syntax of GRANT and DENY Database Privileges"] [[access-control-database-administration-access]] == The database `ACCESS` privilege The `ACCESS` privilege enables users to connect to a database or a remote database alias. -With `ACCESS` you can run calculations, for example, `+RETURN 2 * 5 AS answer+` or call functions `RETURN timestamp() AS time`. +With `ACCESS` you can run calculations, for example, `RETURN 2*5 AS answer` or call functions `RETURN timestamp() AS time`. -[source, syntax, role="noheader", indent=0] +[source, cypher, role=noplay] ---- GRANT ACCESS - ON { HOME DATABASE | DATABASE[S] { * | name[, ...] } } - TO role[, ...] + ON {HOME 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. +For example, to grant the role `regularUsers` the ability to access the database `neo4j`, use: -[source, cypher, role=noplay, indent=0] +[source, cypher, role=noplay] ---- GRANT ACCESS ON DATABASE neo4j TO regularUsers ---- -The `ACCESS` privilege can also be denied. +The `ACCESS` privilege can also be denied: -[source, syntax, role="noheader", indent=0] +[source, cypher, role=noplay] ---- DENY ACCESS - ON { HOME DATABASE | DATABASE[S] { * | name[, ...] } } - TO role[, ...] + ON {HOME DATABASE | DATABASE[S] {* | name[, ...]}} + TO role[, ...] ---- -For example, denying the ability to access to the remote database alias `remote-db` to the role `regularUsers` is done using the following query. +For example, to deny the role `regularUsers` the ability to access to the remote database alias `remote-db`, use: -[source, cypher, role=noplay, indent=0] +[source, cypher, role=noplay] ---- DENY ACCESS ON DATABASE `remote-db` TO regularUsers ---- The privileges granted can be seen using the `SHOW PRIVILEGES` command: -[source, cypher, role=noplay, indent=0] +[source, cypher, role=noplay] ---- SHOW ROLE regularUsers PRIVILEGES AS COMMANDS ---- @@ -520,73 +238,73 @@ a|Rows: 2 [[access-control-database-administration-startstop]] == The database `START`/`STOP` privileges -The `START` privilege can be used to enable the ability to start a database. +The `START` privilege can be used to enable the ability to start a database: -[source, syntax, role="noheader", indent=0] +[source, cypher, role=noplay] ---- GRANT START - ON { HOME DATABASE | DATABASE[S] { * | name[, ...] } } - TO role[, ...] + ON {HOME 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. +For example, to grant the role `regularUsers` the ability to start the database `neo4j`, use: -[source, cypher, role=noplay, indent=0] +[source, cypher, role=noplay] ---- GRANT START ON DATABASE neo4j TO regularUsers ---- -The `START` privilege can also be denied. +The `START` privilege can also be denied: -[source, syntax, role="noheader", indent=0] +[source, cypher, role=noplay] ---- DENY START - ON { HOME DATABASE | DATABASE[S] { * | name[, ...] } } - TO role[, ...] + ON {HOME 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. +For example, to deny the role `regularUsers` the ability to start to the database `neo4j`, use: -[source, cypher, role=noplay, indent=0] +[source, cypher, role=noplay] ---- DENY START ON DATABASE system TO regularUsers ---- -The `STOP` privilege can be used to enable the ability to stop a database. +The `STOP` privilege can be used to enable the ability to stop a database: -[source, syntax, role="noheader", indent=0] +[source, cypher, role=noplay] ---- GRANT STOP - ON { HOME DATABASE | DATABASE[S] { * | name[, ...] } } - TO role[, ...] + ON {HOME 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. +For example, to grant the role `regularUsers` the ability to stop the database `neo4j`, use: -[source, cypher, role=noplay, indent=0] +[source, cypher, role=noplay] ---- GRANT STOP ON DATABASE neo4j TO regularUsers ---- -The `STOP` privilege can also be denied. +The `STOP` privilege can also be denied: -[source, syntax, role="noheader", indent=0] +[source, cypher, role=noplay] ---- DENY STOP - ON { HOME DATABASE | DATABASE[S] { * | name[, ...] } } - TO role[, ...] + ON {HOME 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. +For example, to deny the role `regularUsers` the ability to stop the database `neo4j`, use: -[source, cypher, role=noplay, indent=0] +[source, cypher, role=noplay] ---- DENY STOP ON DATABASE system TO regularUsers ---- The privileges granted can be seen using the `SHOW PRIVILEGES` command: -[source, cypher, role=noplay, indent=0] +[source, cypher, role=noplay] ---- SHOW ROLE regularUsers PRIVILEGES AS COMMANDS ---- @@ -594,7 +312,6 @@ SHOW ROLE regularUsers PRIVILEGES AS COMMANDS .Result [options="header,footer", width="100%", cols="m"] |=== - |command |"DENY ACCESS ON DATABASE `remote-db` TO `regularUsers`" |"DENY START ON DATABASE `system` TO `regularUsers`" @@ -603,12 +320,11 @@ SHOW ROLE regularUsers PRIVILEGES AS COMMANDS |"GRANT START ON DATABASE `neo4j` TO `regularUsers`" |"GRANT STOP ON DATABASE `neo4j` TO `regularUsers`" a|Rows: 6 - |=== [NOTE] ==== -Note that `START` and `STOP` privileges are not included in the xref::access-control/database-administration.adoc#access-control-database-administration-all[`ALL DATABASE PRIVILEGES`]. +Note that `START` and `STOP` privileges are not included in the <>. ==== @@ -619,60 +335,33 @@ Indexes can be created, deleted, or listed with the `CREATE INDEX`, `DROP INDEX` 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. - -.Index management privilege syntax -[cols="<15s,<85"] +.Index management command syntax +[options="header", width="100%", cols="3a,2"] |=== - | Command -m| +GRANT { CREATE \| DROP \| SHOW } INDEX+ - -| Syntax -a| -[source, syntax, role="noheader", indent=0] ----- -GRANT { CREATE \| DROP \| SHOW } INDEX[ES] - ON { HOME DATABASE \| DATABASE[S] { * \| name[, ...] } } - TO role[, ...] ----- - | Description -| Enable the specified roles to create, delete, or show indexes in the home database, specific database(s), or all databases. - -|=== +| [source, cypher, role=noplay] +GRANT {CREATE \| DROP \| SHOW} INDEX[ES] + ON {HOME DATABASE \| DATABASE[S] {* \| name[, ...]}} + TO role[, ...] +| Enables the specified roles to create, delete, or show indexes in the home database, specific database(s), or all databases. - -.Index management privilege syntax -[cols="<15s,<85"] -|=== - -| Command -m| +GRANT INDEX+ - -| Syntax -a| -[source, syntax, role="noheader", indent=0] ----- +| [source, cypher, role=noplay] GRANT INDEX[ES] [MANAGEMENT] - ON { HOME DATABASE \| DATABASE[S] { * \| name[, ...] } } - TO role[, ...] ----- - -| Description -| Enable the specified roles to manage indexes in the home database, specific database(s), or all databases. - + ON {HOME DATABASE \| DATABASE[S] {* \| name[, ...]}} + TO role[, ...] +| Enables the specified roles to manage indexes in the home database, specific database(s), or all databases. |=== +For example, to grant the role `regularUsers` the ability to create indexes on the database `neo4j`, use: -For example, granting the ability to create indexes on the database `neo4j` to the role `regularUsers` is done using the following query. - -[source, cypher, role=noplay, indent=0] +[source, cypher, role=noplay] ---- GRANT CREATE INDEX ON DATABASE neo4j TO regularUsers ---- -The `SHOW INDEXES` privilege only affects the xref::indexes-for-search-performance.adoc#administration-indexes-list-indexes[`SHOW INDEXES` command], and not the older procedures for listing indexes, such as `db.indexes`. +The `SHOW INDEXES` privilege only affects the <>, and not the older procedures for listing indexes, such as `db.indexes`. [[access-control-database-administration-constraints]] @@ -682,159 +371,75 @@ Constraints can be created, deleted, or listed with the `CREATE CONSTRAINT`, `DR 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. - -.Constraint management privilege syntax -[cols="<15s,<85"] +.Constraint management command syntax +[options="header", width="100%", cols="3a,2"] |=== - | Command -m| +GRANT { CREATE \| DROP \| SHOW } CONSTRAINT+ - -| Syntax -a| -[source, syntax, role="noheader", indent=0] ----- -GRANT { CREATE \| DROP \| SHOW } CONSTRAINT[S] - ON { HOME DATABASE \| DATABASE[S] { * \| name[, ...] } } - TO role[, ...] ----- - | Description -| Enable the specified roles to create, delete, or show constraints on the home database, specific database(s), or all databases. -|=== +| [source, cypher, role=noplay] +GRANT {CREATE \| DROP \| SHOW} CONSTRAINT[S] + ON {HOME DATABASE \| DATABASE[S] {* \| name[, ...]}} + TO role[, ...] +| Enables the specified roles to create, delete, or show constraints on the home database, specific database(s), or all databases. - -.Constraint management privilege syntax -[cols="<15s,<85"] -|=== - -| Command -m| +GRANT CONSTRAINT+ - -| Syntax -a| -[source, syntax, role="noheader", indent=0] ----- +| [source, cypher, role=noplay] GRANT CONSTRAINT[S] [MANAGEMENT] - ON { HOME DATABASE \| DATABASE[S] { * \| name[, ...] } } - TO role[, ...] ----- - -| Description -| Enable the specified roles to manage constraints on the home database, specific database(s), or all databases. - + ON {HOME DATABASE \| DATABASE[S] {* \| name[, ...]}} + TO role[, ...] +| Enables the specified roles to manage constraints on the home database, specific database(s), or all databases. |=== +For example, to grant the role `regularUsers` the ability to create constraints on the database `neo4j`, use: -For example, granting the ability to create constraints on the database `neo4j` to the role `regularUsers` is done using the following query. - -[source, cypher, role=noplay, indent=0] +[source, cypher, role=noplay] ---- GRANT CREATE CONSTRAINT ON DATABASE neo4j TO regularUsers ---- -The `SHOW CONSTRAINTS` privilege only affects the xref::constraints/syntax.adoc#administration-constraints-syntax-list[`SHOW CONSTRAINTS` command], and not the older procedures for listing constraints, such as `db.constraints`. +The `SHOW CONSTRAINTS` privilege only affects the <>, and not the older procedures for listing constraints, such as `db.constraints`. [[access-control-database-administration-tokens]] == 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. +The latter is managed using database `WRITE` privileges, while the former is managed using specific `GRANT/DENY CREATE NEW ...` commands for each type. - -.Node label management privileges syntax -[cols="<15s,<85"] +.Label, relationship type and property name management command syntax +[options="header", width="100%", cols="3a,2"] |=== - | Command -m| +GRANT CREATE NEW LABEL+ - -| Syntax -a| -[source, syntax, role="noheader", indent=0] ----- -GRANT CREATE NEW [NODE] LABEL[S] - ON { HOME DATABASE \| DATABASE[S] { * \| name[, ...] } } - TO role[, ...] ----- - | Description -| Enable the specified roles to create new node labels in the home database, specific database(s), or all databases. - -|=== - -.Relationship type management privileges syntax -[cols="<15s,<85"] -|=== - -| Command -m| +GRANT CREATE NEW TYPE+ +| [source, cypher, role=noplay] +GRANT CREATE NEW [NODE] LABEL[S] + ON {HOME DATABASE \| DATABASE[S] {* \| name[, ...]}} + TO role[, ...] +| Enables the specified roles to create new node labels in the home database, specific database(s), or all databases. -| Syntax -a| -[source, syntax, role="noheader", indent=0] ----- +| [source, cypher, role=noplay] GRANT CREATE NEW [RELATIONSHIP] TYPE[S] - ON { HOME DATABASE \| DATABASE[S] { * \| name[, ...] } } - TO role[, ...] ----- - -| Description -| Enable the specified roles to create new relationship types in the home database, specific database(s), or all databases. - -|=== - - -.Property name management privileges syntax -[cols="<15s,<85"] -|=== - -| Command -m| +GRANT CREATE NEW NAME+ + ON {HOME DATABASE \| DATABASE[S] {* \| name[, ...]}} + TO role[, ...] +| Enables the specified roles to create new relationship types in the home database, specific database(s), or all databases. -| Syntax -a| -[source, syntax, role="noheader", indent=0] ----- +| [source, cypher, role=noplay] GRANT CREATE NEW [PROPERTY] NAME[S] - ON { HOME DATABASE \| DATABASE[S] { * \| name[, ...] } } - TO role[, ...] ----- - -| Description -| Enable the specified roles to create new property names in the home database, specific database(s), or all databases. - -|=== - - -.Node label, relationship type, and property name privileges management syntax -[cols="<15s,<85"] -|=== + ON {HOME DATABASE \| DATABASE[S] {* \| name[, ...]}} + TO role[, ...] +| Enables the specified roles to create new property names in the home database, specific database(s), or all databases. -| Command -m| +GRANT NAME+ - -| Syntax -a| -[source, syntax, role="noheader", indent=0] ----- +| [source, cypher, role=noplay] GRANT NAME [MANAGEMENT] - ON { HOME DATABASE \| DATABASE[S] { * \| name[, ...] } } - TO role[, ...] ----- - -| Description -| Enable the specified roles to create new labels, relationship types, and property names in the home database, specific database(s), or all databases. - + ON {HOME DATABASE \| DATABASE[S] {* \| name[, ...]}} + TO role[, ...] +| Enables the specified roles to create new labels, relationship types, and property names in the home database, specific database(s), or all databases. |=== +For example, to grant the role `regularUsers` the ability to create new properties on nodes or relationships on the database `neo4j`, use: -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. - -[source, cypher, role=noplay, indent=0] +[source, cypher, role=noplay] ---- GRANT CREATE NEW PROPERTY NAME ON DATABASE neo4j TO regularUsers ---- @@ -845,11 +450,11 @@ GRANT CREATE NEW PROPERTY NAME ON DATABASE neo4j TO regularUsers 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: -[source, syntax, role="noheader", indent=0] +[source, cypher, role=noplay] ---- GRANT ALL [[DATABASE] PRIVILEGES] - ON { HOME DATABASE | DATABASE[S] { * | name[, ...] } } - TO role[, ...] + ON {HOME DATABASE | DATABASE[S] {* | name[, ...]}} + TO role[, ...] ---- [NOTE] @@ -860,14 +465,14 @@ These privileges are associated with administrators while other database privile For example, granting the abilities above on the database `neo4j` to the role `databaseAdminUsers` is done using the following query. -[source, cypher, role=noplay, indent=0] +[source, cypher, role=noplay] ---- GRANT ALL DATABASE PRIVILEGES ON DATABASE neo4j TO databaseAdminUsers ---- The privileges granted can be seen using the `SHOW PRIVILEGES` command: -[source, cypher, role=noplay, indent=0] +[source, cypher, role=noplay] ---- SHOW ROLE databaseAdminUsers PRIVILEGES AS COMMANDS ---- @@ -884,84 +489,41 @@ a|Rows: 1 [[access-control-database-administration-transaction]] == Granting `TRANSACTION MANAGEMENT` privileges -The right to run the commands `SHOW TRANSACTIONS`, `TERMINATE TRANSACTIONS`, and the deprecated procedures `dbms.listTransactions`, `dbms.listQueries`,`dbms.killQuery`, `dbms.killQueries`, `dbms.killTransaction` and `dbms.killTransactions`, are managed through the `SHOW TRANSACTION` and `TERMINATE TRANSACTION` privileges. - - -.Database privilege syntax -[cols="<15s,<85"] -|=== - -| Command -m| +GRANT SHOW TRANSACTION+ - -| Syntax -a| -[source, syntax, role="noheader", indent=0] ----- -GRANT SHOW TRANSACTION[S] [( { * \| user[, ...] } )] - ON { HOME DATABASE \| DATABASE[S] { * \| name[, ...] } } - TO role[, ...] ----- - -| Description -| Enable the specified roles to list transactions and queries for user(s) or all users in the home database, specific database(s), or all databases. - -|=== - +The right to run the commands `SHOW TRANSACTIONS`, `TERMINATE TRANSACTIONS`, and the deprecated procedures `dbms.listTransactions`, `dbms.listQueries`, `dbms.killQuery`, `dbms.killQueries`, `dbms.killTransaction` and `dbms.killTransactions` is now managed through the `SHOW TRANSACTION` and `TERMINATE TRANSACTION` privileges. -.Database privilege syntax -[cols="<15s,<85"] +.Transaction management command syntax +[options="header", width="100%", cols="3a,2"] |=== - | Command -m| +GRANT TERMINATE TRANSACTION+ - -| Syntax -a| -[source, syntax, role="noheader", indent=0] ----- -GRANT TERMINATE TRANSACTION[S] [( { * \| user[, ...] } )] - ON { HOME DATABASE \| DATABASE[S] { * \| name[, ...] } } - TO role[, ...] ----- - | Description -| Enable the specified roles to end running transactions and queries for user(s) or all users in the home database, specific database(s), or all databases. -|=== +| [source, cypher, role=noplay] +GRANT SHOW TRANSACTION[S] [( {* \| user[, ...]} )] + ON {HOME DATABASE \| DATABASE[S] {* \| name[, ...]}} + TO role[, ...] +| Enables the specified roles to list transactions and queries for user(s) or all users in the home database, specific database(s), or all databases. +| [source, cypher, role=noplay] +GRANT TERMINATE TRANSACTION[S] [( {* \| user[, ...]} )] + ON {HOME DATABASE \| DATABASE[S] {* \| name[, ...]}} + TO role[, ...] +| Enables the specified roles to end running transactions and queries for user(s) or all users in the home database, specific database(s), or all databases. -.Database privilege syntax -[cols="<15s,<85"] +| [source, cypher, role=noplay] +GRANT TRANSACTION [MANAGEMENT] [( {* \| user[, ...]} )] + ON {HOME DATABASE \| DATABASE[S] {* \| name[, ...]}} + TO role[, ...] +| Enables the specified roles to manage transactions and queries for user(s) or all users in the home database, specific database(s), or all databases. |=== -| Command -m| +GRANT TRANSACTION+ - -| Syntax -a| -[source, syntax, role="noheader", indent=0] ----- -GRANT TRANSACTION [MANAGEMENT] [( { * \| user[, ...] } )] - ON { HOME DATABASE \| DATABASE[S] { * \| name[, ...] } } - TO role[, ...] ----- - -| Description -| Enable the specified roles to manage transactions and queries for user(s) or all users in the home database, specific database(s), or all databases. - -|=== - - [NOTE] ==== -Note that the `TRANSACTION MANAGEMENT` privileges are not included in the xref::access-control/database-administration.adoc#access-control-database-administration-all[`ALL DATABASE PRIVILEGES`]. +Note that the `TRANSACTION MANAGEMENT` privileges are not included in 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. +For example, to grant the role `regularUsers` the ability to list transactions for user `jake` on the database `neo4j`, use: -[source, cypher, role=noplay, indent=0] +[source, cypher, role=noplay] ---- GRANT SHOW TRANSACTION (jake) ON DATABASE neo4j TO regularUsers ---- - diff --git a/modules/ROOT/pages/access-control/dbms-administration.adoc b/modules/ROOT/pages/access-control/dbms-administration.adoc index 52f56b09d..a937b6752 100644 --- a/modules/ROOT/pages/access-control/dbms-administration.adoc +++ b/modules/ROOT/pages/access-control/dbms-administration.adoc @@ -1,5 +1,3 @@ -:description: How to use Cypher to manage Neo4j DBMS administrative privileges. - [role=enterprise-edition] [[access-control-dbms-administration]] = DBMS administration @@ -11,13 +9,13 @@ This section explains how to use Cypher to manage Neo4j DBMS administrative priv 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 xref::introduction/neo4j-databases-graphs.adoc[]. +For more details on the differences between graphs, databases and the DBMS, refer to <>. -image::privileges_grant_and_deny_syntax_dbms_privileges.png[title="Syntax of GRANT and DENY DBMS Privileges"] +image::grant-privileges-dbms.png[title="Syntax of GRANT and DENY DBMS Privileges"] -image::privileges_hierarchy_dbms.png[title="DBMS privileges hierarchy"] +image::privilege-hierarchy-dbms.png[title="DBMS privileges hierarchy"] -The xref::access-control/built-in-roles.adoc#access-control-built-in-roles-admin[`admin` role] has a number of built-in privileges. +The <> has a number of built-in privileges. These include: * Create, delete, and modify databases and aliases. @@ -27,59 +25,54 @@ These include: * 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. +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: -* xref::access-control/dbms-administration.adoc#access-control-dbms-administration-role-management[Role management] -* xref::access-control/dbms-administration.adoc#access-control-dbms-administration-user-management[User management] -* xref::access-control/dbms-administration.adoc#access-control-dbms-administration-impersonation[Impersonation privileges management] -* xref::access-control/dbms-administration.adoc#access-control-dbms-administration-database-management[Database management] -* xref::access-control/dbms-administration.adoc#access-control-dbms-administration-alias-management[Alias management] -* xref::access-control/dbms-administration.adoc#access-control-dbms-administration-privilege-management[Privilege management] -* xref::access-control/database-administration.adoc#access-control-database-administration-transaction[Transaction management] -* xref::access-control/dbms-administration.adoc#access-control-dbms-administration-execute[Procedure and user defined function security] - -It is possible to make a custom role with a subset of these privileges. - +* <> +* <> +* <> +* <> +* <> +* <> +* <> +* <> [[access-control-dbms-administration-custom]] == 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. +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, let's create an administrator that can only manage users and roles by using the latter option. +As an example, an administrator role can be created to only manage users and roles by using the second option: -. First we create the new role: +. First, create the new role: + -[source, cypher, role=noplay, indent=0] +[source, cypher, role=noplay] ---- CREATE ROLE usermanager ---- -. Then we grant the privilege to manage users: +. Then grant the privilege to manage users: + -[source, cypher, role=noplay, indent=0] +[source, cypher, role=noplay] ---- GRANT USER MANAGEMENT ON DBMS TO usermanager ---- . And to manage roles: + -[source, cypher, role=noplay, indent=0] +[source, cypher, role=noplay] ---- GRANT ROLE MANAGEMENT ON DBMS TO usermanager ---- -The resulting role has privileges that only allow user and role management: +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: -[source, cypher, role=noplay, indent=0] +[source, cypher, role=noplay] ---- SHOW ROLE usermanager PRIVILEGES AS COMMANDS ---- -Lists all privileges for role `usermanager`: - .Result [options="header,footer", width="100%", cols="m"] |=== @@ -89,45 +82,46 @@ Lists all privileges for role `usermanager`: a|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: +Note that this role doesn't allow all DBMS capabilities. +For example, the role is missing privileges for management, creation and drop of databases as well as execution of `admin` procedures. +To create a more powerful administrator, you can grant a different set of privileges. + +In the following example, a new administrator role is created to perform almost all DBMS capabilities, excluding database management. +However, the role still has some limited database capabilities, such as managing transactions: -. Again, we start by creating a new role: +. Again, start by creating a new role: + -[source, cypher, role=noplay, indent=0] +[source, cypher, role=noplay] ---- CREATE ROLE customAdministrator ---- -. Then we grant the privilege for all DBMS capabilities: +. Then grant the privilege for all DBMS capabilities: + -[source, cypher, role=noplay, indent=0] +[source, cypher, role=noplay] ---- GRANT ALL DBMS PRIVILEGES ON DBMS TO customAdministrator ---- . And explicitly deny the privilege to manage databases and aliases: + -[source, cypher, role=noplay, indent=0] +[source, cypher, role=noplay] ---- DENY DATABASE MANAGEMENT ON DBMS TO customAdministrator ---- -. Thereafter we grant the transaction management privilege: +. Next, grant the transaction management privilege: + -[source, cypher, role=noplay, indent=0] +[source, cypher, role=noplay] ---- GRANT TRANSACTION MANAGEMENT (*) ON DATABASE * TO customAdministrator ---- -The resulting role has privileges that allow all DBMS privileges except creating, dropping, and modifying databases and aliases, as well as managing transactions: +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: -[source, cypher, role=noplay, indent=0] +[source, cypher, role=noplay] ---- SHOW ROLE customAdministrator PRIVILEGES AS COMMANDS ---- -Lists all privileges for role `customAdministrator`: - .Result [options="header,footer", width="100%", cols="m"] |=== @@ -150,67 +144,66 @@ They can be granted, denied and revoked like other privileges. |=== | Command | Description -| [source, cypher, role=noplay, indent=0] +| [source, cypher, role=noplay] GRANT CREATE ROLE ON DBMS TO role[, ...] -| Enable the specified roles to create new roles. +| Enables the specified roles to create new roles. -| [source, cypher, role=noplay, indent=0] +| [source, cypher, role=noplay] GRANT RENAME ROLE ON DBMS TO role[, ...] -| Enable the specified roles to change the name of roles. +| Enables the specified roles to change the name of roles. -| [source, cypher, role=noplay, indent=0] +| [source, cypher, role=noplay] GRANT DROP ROLE ON DBMS TO role[, ...] -| Enable the specified roles to delete roles. +| Enables the specified roles to delete roles. -| [source, cypher, role=noplay, indent=0] +| [source, cypher, role=noplay] GRANT ASSIGN ROLE ON DBMS TO role[, ...] -| Enable the specified roles to assign roles to users. +| Enables the specified roles to assign roles to users. -| [source, cypher, role=noplay, indent=0] +| [source, cypher, role=noplay] GRANT REMOVE ROLE ON DBMS TO role[, ...] -| Enable the specified roles to remove roles from users. +| Enables the specified roles to remove roles from users. -| [source, cypher, role=noplay, indent=0] +| [source, cypher, role=noplay] GRANT SHOW ROLE ON DBMS TO role[, ...] -| Enable the specified roles to list roles. +| Enables the specified roles to list roles. -| [source, cypher, role=noplay, indent=0] +| [source, cypher, role=noplay] GRANT ROLE MANAGEMENT ON DBMS TO role[, ...] -| Enable the specified roles to create, delete, assign, remove, and 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. -The following query shows an example of this: +See an example: -[source, cypher, role=noplay, indent=0] +[source, cypher, role=noplay] ---- GRANT CREATE ROLE ON DBMS TO roleAdder ---- -The resulting role has privileges that only allow adding roles: +The resulting role has privileges that only allow adding roles. +List all privileges for the role `roleAdder` as commands by using the following query: -[source, cypher, role=noplay, indent=0] +[source, cypher, role=noplay] ---- SHOW ROLE roleAdder PRIVILEGES AS COMMANDS ---- -Lists all privileges for role `roleAdder`: - .Result [options="header,footer", width="100%", cols="m"] |=== @@ -220,22 +213,21 @@ a|Rows: 1 |=== The ability to rename roles can be granted via the `RENAME ROLE` privilege. -The following query shows an example of this: +See an example: -[source, cypher, role=noplay, indent=0] +[source, cypher, role=noplay] ---- GRANT RENAME ROLE ON DBMS TO roleNameModifier ---- -The resulting role has privileges that only allow renaming roles: +The resulting role has privileges that only allow renaming roles. +List all privileges for the role `roleNameModifier` using the following query: -[source, cypher, role=noplay, indent=0] +[source, cypher, role=noplay] ---- SHOW ROLE roleNameModifier PRIVILEGES AS COMMANDS ---- -Lists all privileges for role `roleNameModifier`: - .Result [options="header,footer", width="100%", cols="m"] |=== @@ -245,22 +237,21 @@ a|Rows: 1 |=== The ability to delete roles can be granted via the `DROP ROLE` privilege. -The following query shows an example of this: +See an example: -[source, cypher, role=noplay, indent=0] +[source, cypher, role=noplay] ---- GRANT DROP ROLE ON DBMS TO roleDropper ---- -The resulting role has privileges that only allow deleting roles: +The resulting role has privileges that only allow deleting roles. +List all privileges for the role `roleDropper` by using the following query: -[source, cypher, role=noplay, indent=0] +[source, cypher, role=noplay] ---- SHOW ROLE roleDropper PRIVILEGES AS COMMANDS ---- -Lists all privileges for role `roleDropper`: - .Result [options="header,footer", width="100%", cols="m"] |=== @@ -270,22 +261,21 @@ a|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: +See an example: -[source, cypher, role=noplay, indent=0] +[source, cypher, role=noplay] ---- GRANT ASSIGN ROLE ON DBMS TO roleAssigner ---- -The resulting role has privileges that only allow assigning/granting roles: +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: -[source, cypher, role=noplay, indent=0] +[source, cypher, role=noplay] ---- SHOW ROLE roleAssigner PRIVILEGES AS COMMANDS ---- -Lists all privileges for role `roleAssigner`: - .Result [options="header,footer", width="100%", cols="m"] |=== @@ -295,22 +285,21 @@ a|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: +See an example: -[source, cypher, role=noplay, indent=0] +[source, cypher, role=noplay] ---- GRANT REMOVE ROLE ON DBMS TO roleRemover ---- -The resulting role has privileges that only allow removing/revoking roles: +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: -[source, cypher, role=noplay, indent=0] +[source, cypher, role=noplay] ---- SHOW ROLE roleRemover PRIVILEGES AS COMMANDS ---- -Lists all privileges for role `roleRemover`: - .Result [options="header,footer", width="100%", cols="m"] |=== @@ -321,23 +310,23 @@ a|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: -[source, cypher, role=noplay, indent=0] +In order to use `SHOW ROLES WITH USERS` and `SHOW POPULATED ROLES WITH USERS` administration commands, both this and the `SHOW USER` privileges are required. +See an example of how to grant the `SHOW ROLE` privilege: + +[source, cypher, role=noplay] ---- GRANT SHOW ROLE ON DBMS TO roleShower ---- -The resulting role has privileges that only allow showing roles: +The resulting role has privileges that only allow showing roles. +List all privileges for the role `roleShower` as commands by using the following query: -[source, cypher, role=noplay, indent=0] +[source, cypher, role=noplay] ---- SHOW ROLE roleShower PRIVILEGES AS COMMANDS ---- -Lists all privileges for role `roleShower`: - .Result [options="header,footer", width="100%", cols="m"] |=== @@ -347,22 +336,21 @@ a|Rows: 1 |=== The privileges to create, rename, delete, assign, remove, and list roles can be granted via the `ROLE MANAGEMENT` privilege. -The following query shows an example of this: +See an example: -[source, cypher, role=noplay, indent=0] +[source, cypher, role=noplay] ---- GRANT ROLE MANAGEMENT ON DBMS TO roleManager ---- -The resulting role has all privileges to manage roles: +The resulting role has all privileges to manage roles. +List all privileges for the role `roleManager` as commands by using the following query: -[source, cypher, role=noplay, indent=0] +[source, cypher, role=noplay] ---- SHOW ROLE roleManager PRIVILEGES AS COMMANDS ---- -Lists all privileges for role `roleManager`: - .Result [options="header,footer", width="100%", cols="m"] |=== @@ -375,7 +363,7 @@ a|Rows: 1 [[access-control-dbms-administration-user-management]] == The DBMS `USER MANAGEMENT` privileges -The DBMS privileges for user management are assignable using Cypher administrative commands. +The DBMS privileges for user management can be assigned using Cypher administrative commands. They can be granted, denied and revoked like other privileges. .User management privileges command syntax @@ -383,79 +371,78 @@ They can be granted, denied and revoked like other privileges. |=== | Command | Description -| [source, cypher, role=noplay, indent=0] +| [source, cypher, role=noplay] GRANT CREATE USER ON DBMS TO role[, ...] -| Enable the specified roles to create new users. +| Enables the specified roles to create new users. -| [source, cypher, role=noplay, indent=0] +| [source, cypher, role=noplay] GRANT RENAME USER ON DBMS TO role[, ...] -| Enable the specified roles to change the name of users. +| Enables the specified roles to change the name of users. -| [source, cypher, role=noplay, indent=0] +| [source, cypher, role=noplay] GRANT ALTER USER ON DBMS TO role[, ...] -| Enable the specified roles to modify users. +| Enables the specified roles to modify users. -| [source, cypher, role=noplay, indent=0] +| [source, cypher, role=noplay] 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. +| Enables the specified roles to modify users' passwords and whether those passwords must be changed upon first login. -| [source, cypher, role=noplay, indent=0] +| [source, cypher, role=noplay] GRANT SET USER HOME DATABASE ON DBMS TO role[, ...] -| Enable the specified roles to modify users' home database. +| Enables the specified roles to modify users' home database. -| [source, cypher, role=noplay, indent=0] +| [source, cypher, role=noplay] GRANT SET USER STATUS ON DBMS TO role[, ...] -| Enable the specified roles to modify the account status of users. +| Enables the specified roles to modify the account status of users. -| [source, cypher, role=noplay, indent=0] +| [source, cypher, role=noplay] GRANT DROP USER ON DBMS TO role[, ...] -| Enable the specified roles to delete users. +| Enables the specified roles to delete users. -| [source, cypher, role=noplay, indent=0] +| [source, cypher, role=noplay] GRANT SHOW USER ON DBMS TO role[, ...] -| Enable the specified roles to list users. +| Enables the specified roles to list users. -| [source, cypher, role=noplay, indent=0] +| [source, cypher, role=noplay] GRANT USER MANAGEMENT ON DBMS TO role[, ...] -| Enable the specified roles to create, delete, modify, and 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. -The following query shows an example of this: +See an example: -[source, cypher, role=noplay, indent=0] +[source, cypher, role=noplay] ---- GRANT CREATE USER ON DBMS TO userAdder ---- -The resulting role has privileges that only allow adding users: +The resulting role has privileges that only allow adding users. +List all privileges for the role `userAdder` as commands by using this query: -[source, cypher, role=noplay, indent=0] +[source, cypher, role=noplay] ---- SHOW ROLE userAdder PRIVILEGES AS COMMANDS ---- -Lists all privileges for role `userAdder`: - .Result [options="header,footer", width="100%", cols="m"] |=== @@ -467,14 +454,14 @@ a|Rows: 1 The ability to rename users can be granted via the `RENAME USER` privilege. The following query shows an example of this: -[source, cypher, role=noplay, indent=0] +[source, cypher, role=noplay] ---- GRANT RENAME USER ON DBMS TO userNameModifier ---- The resulting role has privileges that only allow renaming users: -[source, cypher, role=noplay, indent=0] +[source, cypher, role=noplay] ---- SHOW ROLE userNameModifier PRIVILEGES AS COMMANDS ---- @@ -490,22 +477,21 @@ a|Rows: 1 |=== The ability to modify users can be granted via the `ALTER USER` privilege. -The following query shows an example of this: +See an example: -[source, cypher, role=noplay, indent=0] +[source, cypher, role=noplay] ---- GRANT ALTER USER ON DBMS TO userModifier ---- -The resulting role has privileges that only allow modifying users: +The resulting role has privileges that only allow modifying users. +List all privileges for the role `userModifier` as commands by using the following query: -[source, cypher, role=noplay, indent=0] +[source, cypher, role=noplay] ---- SHOW ROLE userModifier PRIVILEGES AS COMMANDS ---- -Lists all privileges for role `userModifier`: - .Result [options="header,footer", width="100%", cols="m"] |=== @@ -514,30 +500,29 @@ Lists all privileges for role `userModifier`: a|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: +A user that is granted the `ALTER USER` privilege is allowed to run the `ALTER USER` administration command with one or several of the `SET PASSWORD`, `SET PASSWORD CHANGE [NOT] REQUIRED` and `SET STATUS` parts: -[source, cypher, role=noplay, indent=0] +[source, cypher, role=noplay] ---- ALTER USER jake SET PASSWORD 'secret' SET STATUS SUSPENDED ---- The ability to modify users' passwords and whether those passwords must be changed upon first login can be granted via the `SET PASSWORDS` privilege. -The following query shows an example of this: +See an example: -[source, cypher, role=noplay, indent=0] +[source, cypher, role=noplay] ---- 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: +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: -[source, cypher, role=noplay, indent=0] +[source, cypher, role=noplay] ---- SHOW ROLE passwordModifier PRIVILEGES AS COMMANDS ---- -Lists all privileges for role `passwordModifier`: - .Result [options="header,footer", width="100%", cols="m"] |=== @@ -546,30 +531,29 @@ Lists all privileges for role `passwordModifier`: a|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: +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: -[source, cypher, role=noplay, indent=0] +[source, cypher, role=noplay] ---- ALTER USER jake SET PASSWORD 'abc123' CHANGE NOT REQUIRED ---- The ability to modify the account status of users can be granted via the `SET USER STATUS` privilege. -The following query shows an example of this: +See an example: -[source, cypher, role=noplay, indent=0] +[source, cypher, role=noplay] ---- GRANT SET USER STATUS ON DBMS TO statusModifier ---- -The resulting role has privileges that only allow modifying the account status of users: +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: -[source, cypher, role=noplay, indent=0] +[source, cypher, role=noplay] ---- SHOW ROLE statusModifier PRIVILEGES AS COMMANDS ---- -Lists all privileges for role `statusModifier`: - .Result [options="header,footer", width="100%", cols="m"] |=== @@ -578,30 +562,29 @@ Lists all privileges for role `statusModifier`: a|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: +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: -[source, cypher, role=noplay, indent=0] +[source, cypher, role=noplay] ---- ALTER USER jake SET STATUS ACTIVE ---- -The ability to modify the home database of users can be granted via the `SET USER HOME DATABASE` privilege. -The following query shows an example of this: +In order to be able to modify the home database of users, grant the `SET USER HOME DATABASE` privilege. +See an example: -[source, cypher, role=noplay, indent=0] +[source, cypher, role=noplay] ---- GRANT SET USER HOME DATABASE ON DBMS TO statusModifier ---- -The resulting role has privileges that only allow modifying the home database of users: +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: -[source, cypher, role=noplay, indent=0] +[source, cypher, role=noplay] ---- SHOW ROLE statusModifier PRIVILEGES AS COMMANDS ---- -Lists all privileges for role `statusModifier`: - .Result [options="header,footer", width="100%", cols="m"] |=== @@ -611,14 +594,14 @@ Lists all privileges for role `statusModifier`: a|Rows: 2 |=== -A user that is granted `SET USER HOME DATABASE` is allowed to run the `ALTER USER` administration command with only the `SET HOME DATABASE` or `REMOVE HOME DATABASE` part: +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: -[source, cypher, role=noplay, indent=0] +[source, cypher, role=noplay] ---- ALTER USER jake SET HOME DATABASE otherDb ---- -[source, cypher, role=noplay, indent=0] +[source, cypher, role=noplay] ---- ALTER USER jake REMOVE HOME DATABASE ---- @@ -629,22 +612,21 @@ Note that the combination of the `SET PASSWORDS`, `SET USER STATUS`, and the `SE ==== The ability to delete users can be granted via the `DROP USER` privilege. -The following query shows an example of this: +See an example: -[source, cypher, role=noplay, indent=0] +[source, cypher, role=noplay] ---- GRANT DROP USER ON DBMS TO userDropper ---- -The resulting role has privileges that only allow deleting users: +The resulting role has privileges that only allow deleting users. +List all privileges for the role `userDropper` as commands by using the following query: -[source, cypher, role=noplay, indent=0] +[source, cypher, role=noplay] ---- SHOW ROLE userDropper PRIVILEGES AS COMMANDS ---- -Lists all privileges for role `userDropper`: - .Result [options="header,footer", width="100%", cols="m"] |=== @@ -654,22 +636,21 @@ a|Rows: 1 |=== The ability to show users can be granted via the `SHOW USER` privilege. -The following query shows an example of this: +See an example: -[source, cypher, role=noplay, indent=0] +[source, cypher, role=noplay] ---- GRANT SHOW USER ON DBMS TO userShower ---- -The resulting role has privileges that only allow showing users: +The resulting role has privileges that only allow showing users. +List all privileges for the role `userShower` as commands by using the following query: -[source, cypher, role=noplay, indent=0] +[source, cypher, role=noplay] ---- SHOW ROLE userShower PRIVILEGES AS COMMANDS ---- -Lists all privileges for role `userShower`: - .Result [options="header,footer", width="100%", cols="m"] |=== @@ -679,27 +660,36 @@ a|Rows: 1 |=== The privileges to create, rename, modify, delete, and list users can be granted via the `USER MANAGEMENT` privilege. -The following query shows an example of this: +See an example: -[source, cypher, role=noplay, indent=0] +[source, cypher, role=noplay] ---- GRANT USER MANAGEMENT ON DBMS TO userManager ---- -The resulting role has all privileges to manage users: +The resulting role has all privileges to manage users. +List all privileges for the role `userManager` as commands by using the following query: -[source, cypher, role=noplay, indent=0] +[source, cypher, role=noplay] ---- SHOW ROLE userManager PRIVILEGES AS COMMANDS ---- +.Result +[options="header,footer", width="100%", cols="m"] +|=== +|command +|"GRANT SHOW USER ON DBMS TO `userManager`" +a|Rows: 1 +|=== [[access-control-dbms-administration-impersonation]] == The DBMS `IMPERSONATE` privileges -The DBMS privileges for impersonation are assignable using Cypher administrative commands. +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 capability 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). + +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. @@ -708,24 +698,25 @@ The ability to impersonate users can be granted via the `IMPERSONATE` privilege. |=== | Command | Description -| [source, cypher, role=noplay, indent=0] +| [source, cypher, role=noplay] GRANT IMPERSONATE [(*)] ON DBMS TO role[, ...] -| Enable the specified roles to impersonate any user. +| Enables the specified roles to impersonate any user. -| [source, cypher, role=noplay, indent=0] +| [source, cypher, role=noplay] GRANT IMPERSONATE (user[, ...]) ON DBMS TO role[, ...] -| Enable the specified roles to impersonate the specified users. +| Enables the specified roles to impersonate the specified users. |=== -The following query shows an example of this (where `userImpersonator` must be an existing role): +The following query shows an example of this. +Note that `userImpersonator` must be an existing role in order to make this query work: .Query -[source, cypher, role=noplay, indent=0] +[source, cypher, role=noplay] ---- GRANT IMPERSONATE (*) ON DBMS TO userImpersonator ---- @@ -733,7 +724,7 @@ GRANT IMPERSONATE (*) ON DBMS TO userImpersonator The resulting role has privileges that allow impersonating all users: .Query -[source, cypher, role=noplay, indent=0] +[source, cypher, role=noplay] ---- SHOW ROLE userImpersonator PRIVILEGES AS COMMANDS ---- @@ -747,18 +738,18 @@ a|Rows: 1 |=== It is also possible to deny and revoke that privilege. -The following example shows how the `userImpersonator` user would be able to impersonate all users, except for `alice`: +See an example which shows of how the `userImpersonator` user would be able to impersonate all users, except `alice`: .Query -[source, cypher, role=noplay, indent=0] +[source, cypher, role=noplay] ---- 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 do so by listing them in the command: +To grant (or revoke) the permissions to impersonate a specific user or a subset of users, you can first list them with this query: .Query -[source, cypher, role=noplay, indent=0] +[source, cypher, role=noplay] ---- GRANT IMPERSONATE (alice, bob) ON DBMS TO userImpersonator ---- @@ -767,63 +758,62 @@ GRANT IMPERSONATE (alice, bob) ON DBMS TO userImpersonator [[access-control-dbms-administration-database-management]] == 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. +The DBMS privileges for database management can be assigned by using Cypher administrative commands. They can be granted, denied and revoked like other privileges. .Database management privileges command syntax [options="header", width="100%", cols="3a,2"] |=== | Command | Description -| [source, cypher, role=noplay, indent=0] +| [source, cypher, role=noplay] GRANT CREATE DATABASE ON DBMS TO role[, ...] -| Enable the specified roles to create new databases and aliases. +| Enables the specified roles to create new databases and aliases. -| [source, cypher, role=noplay, indent=0] +| [source, cypher, role=noplay] GRANT DROP DATABASE ON DBMS TO role[, ...] -| Enable the specified roles to delete databases and aliases. +| Enables the specified roles to delete databases and aliases. -| [source, cypher, role=noplay, indent=0] +| [source, cypher, role=noplay] GRANT ALTER DATABASE ON DBMS TO role[, ...] -| Enable the specified roles to modify databases and aliases. +| Enables the specified roles to modify databases and aliases. -| [source, cypher, role=noplay, indent=0] +| [source, cypher, role=noplay] GRANT SET DATABASE ACCESS ON DBMS TO role[, ...] -| Enable the specified roles to modify access of databases. +| Enables the specified roles to modify access of databases. -| [source, cypher, role=noplay, indent=0] +| [source, cypher, role=noplay] GRANT DATABASE MANAGEMENT ON DBMS TO role[, ...] -| Enable the specified roles to create, delete, and modify databases and aliases. +| Enables the specified roles to create, delete, and modify databases and aliases. |=== The ability to create databases and aliases can be granted via the `CREATE DATABASE` privilege. -The following query shows an example of this: +See an example: -[source, cypher, role=noplay, indent=0] +[source, cypher, role=noplay] ---- GRANT CREATE DATABASE ON DBMS TO databaseAdder ---- -The resulting role has privileges that only allow creating databases and aliases: +The resulting role has privileges that only allow creating databases and aliases. +List all privileges for the role `databaseAdder` as commands by using the following query: -[source, cypher, role=noplay, indent=0] +[source, cypher, role=noplay] ---- SHOW ROLE databaseAdder PRIVILEGES AS COMMANDS ---- -Lists all privileges for role `databaseAdder`: - .Result [options="header,footer", width="100%", cols="m"] |=== @@ -833,22 +823,21 @@ a|Rows: 1 |=== The ability to delete databases and aliases can be granted via the `DROP DATABASE` privilege. -The following query shows an example of this: +See an example: -[source, cypher, role=noplay, indent=0] +[source, cypher, role=noplay] ---- GRANT DROP DATABASE ON DBMS TO databaseDropper ---- -The resulting role has privileges that only allow deleting databases and aliases: +The resulting role has privileges that only allow deleting databases and aliases. +List all privileges for the role `databaseDropper` as commands by using the following query: -[source, cypher, role=noplay, indent=0] +[source, cypher, role=noplay] ---- SHOW ROLE databaseDropper PRIVILEGES AS COMMANDS ---- -Lists all privileges for role `databaseDropper`: - .Result [options="header,footer", width="100%", cols="m"] |=== @@ -858,22 +847,21 @@ a|Rows: 1 |=== The ability to modify databases and aliases can be granted via the `ALTER DATABASE` privilege. -The following query shows an example of this: +See an example: -[source, cypher, role=noplay, indent=0] +[source, cypher, role=noplay] ---- GRANT ALTER DATABASE ON DBMS TO databaseModifier ---- -The resulting role has privileges that only allow modifying databases and aliases: +The resulting role has privileges that only allow modifying databases and aliases. +List all privileges for the role `databaseModifier` as commands by using the following query: -[source, cypher, role=noplay, indent=0] +[source, cypher, role=noplay] ---- SHOW ROLE databaseModifier PRIVILEGES AS COMMANDS ---- -Lists all privileges for role `databaseModifier`: - .Result [options="header,footer", width="100%", cols="m"] |=== @@ -883,22 +871,21 @@ a|Rows: 1 |=== The ability to modify access of databases can be granted via the `SET DATABASE ACCESS` privilege. -The following query shows an example of this: +See an example: -[source, cypher, role=noplay, indent=0] +[source, cypher, role=noplay] ---- GRANT SET DATABASE ACCESS ON DBMS TO accessModifier ---- -The resulting role has privileges that only allow modifying access of databases: +The resulting role has privileges that only allow modifying access of databases. +List all privileges for the role `accessModifier` as commands by using the following query: -[source, cypher, role=noplay, indent=0] +[source, cypher, role=noplay] ---- SHOW ROLE accessModifier PRIVILEGES AS COMMANDS ---- -Lists all privileges for role `accessModifier`: - .Result [options="header,footer", width="100%", cols="m"] |=== @@ -908,22 +895,21 @@ a|Rows: 1 |=== The privileges to create, delete, and modify databases and aliases can be granted via the `DATABASE MANAGEMENT` privilege. -The following query shows an example of this: +See an example: -[source, cypher, role=noplay, indent=0] +[source, cypher, role=noplay] ---- GRANT DATABASE MANAGEMENT ON DBMS TO databaseManager ---- -The resulting role has all privileges to manage databases and aliases: +The resulting role has all privileges to manage databases and aliases. +List all privileges for the role `databaseManager` as commands by using the following query: -[source, cypher, role=noplay, indent=0] +[source, cypher, role=noplay] ---- SHOW ROLE databaseManager PRIVILEGES AS COMMANDS ---- -Lists all privileges for role `databaseManager`: - .Result [options="header,footer", width="100%", cols="m"] |=== @@ -935,64 +921,63 @@ a|Rows: 1 [[access-control-dbms-administration-alias-management]] == The DBMS `ALIAS MANAGEMENT` privileges -The DBMS privileges for alias management are assignable using Cypher administrative commands and apply to both local and remote aliases. +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 the xref::access-control/dbms-administration.adoc#access-control-dbms-administration-database-management[database management commands]. +It is also possible to manage aliases with <>. .Alias management privileges command syntax [options="header", width="100%", cols="3a,2"] |=== | Command | Description -| [source, cypher, role=noplay, indent=0] +| [source, cypher, role=noplay] GRANT CREATE ALIAS ON DBMS TO role[, ...] -| Enable the specified roles to create new aliases. +| Enables the specified roles to create new aliases. -| [source, cypher, role=noplay, indent=0] +| [source, cypher, role=noplay] GRANT DROP ALIAS ON DBMS TO role[, ...] -| Enable the specified roles to delete aliases. +| Enables the specified roles to delete aliases. -| [source, cypher, role=noplay, indent=0] +| [source, cypher, role=noplay] GRANT ALTER ALIAS ON DBMS TO role[, ...] -| Enable the specified roles to modify aliases. +| Enables the specified roles to modify aliases. -| [source, cypher, role=noplay, indent=0] +| [source, cypher, role=noplay] GRANT SHOW ALIAS ON DBMS TO role[, ...] -| Enable the specified roles to list aliases. +| Enables the specified roles to list aliases. -| [source, cypher, role=noplay, indent=0] +| [source, cypher, role=noplay] GRANT ALIAS MANAGEMENT ON DBMS TO role[, ...] -| Enable the specified roles to list, create, delete, and modify 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. -The following query shows an example of this: +See an example: -[source, cypher, role=noplay, indent=0] +[source, cypher, role=noplay] ---- GRANT CREATE ALIAS ON DBMS TO aliasAdder ---- -The resulting role has privileges that only allow creating aliases: +The resulting role has privileges that only allow creating aliases. +List all privileges for the role `aliasAdder` as commands by using the following query: -[source, cypher, role=noplay, indent=0] +[source, cypher, role=noplay] ---- SHOW ROLE aliasAdder PRIVILEGES AS COMMANDS ---- -Lists all privileges for role `aliasAdder`: - .Result [options="header,footer", width="100%", cols="m"] |=== @@ -1002,22 +987,21 @@ a|Rows: 1 |=== The ability to delete aliases can be granted via the `DROP ALIAS` privilege. -The following query shows an example of this: +See an example: -[source, cypher, role=noplay, indent=0] +[source, cypher, role=noplay] ---- GRANT DROP ALIAS ON DBMS TO aliasDropper ---- -The resulting role has privileges that only allow deleting aliases: +The resulting role has privileges that only allow deleting aliases. +See all privileges for the role `aliasDropper` as commands by using the following query: -[source, cypher, role=noplay, indent=0] +[source, cypher, role=noplay] ---- SHOW ROLE aliasDropper PRIVILEGES AS COMMANDS ---- -Lists all privileges for role `aliasDropper`: - .Result [options="header,footer", width="100%", cols="m"] |=== @@ -1027,22 +1011,21 @@ a|Rows: 1 |=== The ability to modify aliases can be granted via the `ALTER ALIAS` privilege. -The following query shows an example of this: +See an example: -[source, cypher, role=noplay, indent=0] +[source, cypher, role=noplay] ---- GRANT ALTER ALIAS ON DBMS TO aliasModifier ---- -The resulting role has privileges that only allow modifying aliases: +The resulting role has privileges that only allow modifying aliases. +List all privileges for the role `aliasModifier` as commands by using the following query: -[source, cypher, role=noplay, indent=0] +[source, cypher, role=noplay] ---- SHOW ROLE aliasModifier PRIVILEGES AS COMMANDS ---- -Lists all privileges for role `aliasModifier`: - .Result [options="header,footer", width="100%", cols="m"] |=== @@ -1052,22 +1035,21 @@ a|Rows: 1 |=== The ability to list aliases can be granted via the `SHOW ALIAS` privilege. -The following query shows an example of this: +See an example: -[source, cypher, role=noplay, indent=0] +[source, cypher, role=noplay] ---- GRANT SHOW ALIAS ON DBMS TO aliasLister ---- -The resulting role has privileges that only allow modifying aliases: +The resulting role has privileges that only allow modifying aliases. +List all privileges for the role `aliasLister` as commands by using the following query: -[source, cypher, role=noplay, indent=0] +[source, cypher, role=noplay] ---- SHOW ROLE aliasLister PRIVILEGES AS COMMANDS ---- -Lists all privileges for role `aliasLister`: - .Result [options="header,footer", width="100%", cols="m"] |=== @@ -1077,22 +1059,21 @@ a|Rows: 1 |=== The privileges to list, create, delete, and modify aliases can be granted via the `ALIAS MANAGEMENT` privilege. -The following query shows an example of this: +See an example: -[source, cypher, role=noplay, indent=0] +[source, cypher, role=noplay] ---- GRANT ALIAS MANAGEMENT ON DBMS TO aliasManager ---- -The resulting role has all privileges to manage aliases: +The resulting role has all privileges to manage aliases. +List all privileges for the role `aliasManager` as commands by using the following query: -[source, cypher, role=noplay, indent=0] +[source, cypher, role=noplay] ---- SHOW ROLE aliasManager PRIVILEGES AS COMMANDS ---- -Lists all privileges for role `aliasManager`: - .Result [options="header,footer", width="100%", cols="m"] |=== @@ -1104,7 +1085,7 @@ a|Rows: 1 [[access-control-dbms-administration-privilege-management]] == The DBMS `PRIVILEGE MANAGEMENT` privileges -The DBMS privileges for privilege management are assignable using Cypher administrative commands. +The DBMS privileges for privilege management can be assigned by using Cypher administrative commands. They can be granted, denied and revoked like other privileges. .Privilege management privileges command syntax @@ -1112,50 +1093,49 @@ They can be granted, denied and revoked like other privileges. |=== | Command | Description -| [source, cypher, role=noplay, indent=0] +| [source, cypher, role=noplay] GRANT SHOW PRIVILEGE ON DBMS TO role[, ...] -| Enable the specified roles to list privileges. +| Enables the specified roles to list privileges. -| [source, cypher, role=noplay, indent=0] +| [source, cypher, role=noplay] GRANT ASSIGN PRIVILEGE ON DBMS TO role[, ...] -| Enable the specified roles to assign privileges using the `GRANT` and `DENY` commands. +| Enables the specified roles to assign privileges using the `GRANT` and `DENY` commands. -| [source, cypher, role=noplay, indent=0] +| [source, cypher, role=noplay] GRANT REMOVE PRIVILEGE ON DBMS TO role[, ...] -| Enable the specified roles to remove privileges using the `REVOKE` command. +| Enables the specified roles to remove privileges using the `REVOKE` command. -| [source, cypher, role=noplay, indent=0] +| [source, cypher, role=noplay] GRANT PRIVILEGE MANAGEMENT ON DBMS TO role[, ...] -| Enable the specified roles to list, assign, and remove privileges. +| 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. -For the `SHOW USER username PRIVILEGES` administration command, both this privilege and the `SHOW USER` privilege are required. +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: -[source, cypher, role=noplay, indent=0] +[source, cypher, role=noplay] ---- GRANT SHOW PRIVILEGE ON DBMS TO privilegeShower ---- -The resulting role has privileges that only allow showing privileges: +The resulting role has privileges that only allow showing privileges. +List all privileges for the role `privilegeShower` as commands by using the following query: -[source, cypher, role=noplay, indent=0] +[source, cypher, role=noplay] ---- SHOW ROLE privilegeShower PRIVILEGES AS COMMANDS ---- -Lists all privileges for role `privilegeShower`: - .Result [options="header,footer", width="100%", cols="m"] |=== @@ -1166,30 +1146,29 @@ a|Rows: 1 [NOTE] ==== -Note that no specific privileges are required for showing the current user's privileges using either `SHOW USER _username_ PRIVILEGES`, or `SHOW USER PRIVILEGES`. +Note that no specific privileges are required for showing the current user's privileges through the `SHOW USER _username_ PRIVILEGES` or `SHOW USER PRIVILEGES` commands. -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. +In addition, note that if a non-native auth provider like LDAP is in use, `SHOW USER PRIVILEGES` will only work with a limited capacity by making it only possible for a user to show their own privileges. Other users' privileges cannot be listed when using a non-native auth provider. ==== The ability to assign privileges to roles can be granted via the `ASSIGN PRIVILEGE` privilege. -A user with this privilege is allowed to execute GRANT and DENY administration commands. -The following query shows an example of how to grant this privilege: +A user with this privilege is allowed to execute `GRANT` and `DENY` administration commands. +See an example of how to grant this privilege: -[source, cypher, role=noplay, indent=0] +[source, cypher, role=noplay] ---- GRANT ASSIGN PRIVILEGE ON DBMS TO privilegeAssigner ---- -The resulting role has privileges that only allow assigning privileges: +The resulting role has privileges that only allow assigning privileges. +List all privileges for the role `privilegeAssigner` as commands by using the following query: -[source, cypher, role=noplay, indent=0] +[source, cypher, role=noplay] ---- SHOW ROLE privilegeAssigner PRIVILEGES AS COMMANDS ---- -Lists all privileges for role `privilegeAssigner`: - .Result [options="header,footer", width="100%", cols="m"] |=== @@ -1199,23 +1178,22 @@ a|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: +A user with this privilege is allowed to execute `REVOKE` administration commands. +See an example of how to grant this privilege: -[source, cypher, role=noplay, indent=0] +[source, cypher, role=noplay] ---- GRANT REMOVE PRIVILEGE ON DBMS TO privilegeRemover ---- -The resulting role has privileges that only allow removing privileges: +The resulting role has privileges that only allow removing privileges. +List all privileges for the role `privilegeRemover` as commands by using the following query: -[source, cypher, role=noplay, indent=0] +[source, cypher, role=noplay] ---- SHOW ROLE privilegeRemover PRIVILEGES AS COMMANDS ---- -Lists all privileges for role `privilegeRemover`: - .Result [options="header,footer", width="100%", cols="m"] |=== @@ -1225,22 +1203,21 @@ a|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: +See an example: -[source, cypher, role=noplay, indent=0] +[source, cypher, role=noplay] ---- GRANT PRIVILEGE MANAGEMENT ON DBMS TO privilegeManager ---- -The resulting role has all privileges to manage privileges: +The resulting role has all privileges to manage privileges. +List all privileges for the role `privilegeManager` as commands by using the following query: -[source, cypher, role=noplay, indent=0] +[source, cypher, role=noplay] ---- SHOW ROLE privilegeManager PRIVILEGES AS COMMANDS ---- -Lists all privileges for role `privilegeManager`: - .Result [options="header,footer", width="100%", cols="m"] |=== @@ -1253,7 +1230,7 @@ a|Rows: 1 [[access-control-dbms-administration-execute]] == The DBMS `EXECUTE` privileges -The DBMS privileges for procedure and user defined function execution are assignable using Cypher administrative commands. +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. .Execute privileges command syntax @@ -1262,39 +1239,39 @@ They can be granted, denied and revoked like other privileges. | Command | Description -| [source, cypher, role=noplay, indent=0] +| [source, cypher, role=noplay] GRANT EXECUTE PROCEDURE[S] name-globbing[, ...] ON DBMS TO role[, ...] -| Enable the specified roles to execute the given procedures. +| Enables the specified roles to execute the given procedures. -| [source, cypher, role=noplay, indent=0] +| [source, cypher, role=noplay] GRANT EXECUTE BOOSTED PROCEDURE[S] name-globbing[, ...] ON DBMS TO role[, ...] -| Enable the specified roles to execute the given procedures with elevated privileges. +| Enables the specified roles to execute the given procedures with elevated privileges. -| [source, cypher, role=noplay, indent=0] +| [source, cypher, role=noplay] 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. +| Enables the specified roles to execute procedures annotated with `@Admin`. The procedures are executed with elevated privileges. -| [source, cypher, role=noplay, indent=0] +| [source, cypher, role=noplay] GRANT EXECUTE [USER [DEFINED]] FUNCTION[S] name-globbing[, ...] ON DBMS TO role[, ...] -| Enable the specified roles to execute the given user defined functions. +| Enables the specified roles to execute the given user defined functions. -| [source, cypher, role=noplay, indent=0] +| [source, cypher, role=noplay] 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. +| Enables the specified roles to execute the given user defined functions with elevated privileges. |=== The `EXECUTE BOOSTED` privileges replace the `dbms.security.procedures.default_allowed` and `dbms.security.procedures.roles` configuration parameters for procedures and user defined functions. -The configuration parameters are still honoured as a set of temporary privileges. +The configuration parameters are still honored as a set of temporary privileges. These cannot be revoked, but will be updated on each restart with the current configuration values. @@ -1302,25 +1279,25 @@ These cannot be revoked, but will be updated on each restart with the current co === 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 xref::access-control/dbms-administration.adoc#access-control-name-globbing[name-globbing]. +A user with this privilege is allowed to execute the procedures matched by the <>. The following query shows an example of how to grant this privilege: -[source, cypher, role=noplay, indent=0] +[source, cypher, role=noplay] ---- GRANT EXECUTE PROCEDURE db.schema.* ON DBMS TO procedureExecutor ---- -Users with the role 'procedureExecutor' can then run any procedure in the `db.schema` namespace. +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: -[source, cypher, role=noplay, indent=0] +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: + +[source, cypher, role=noplay] ---- SHOW ROLE procedureExecutor PRIVILEGES AS COMMANDS ---- -Lists all privileges for role `procedureExecutor`: - .Result [options="header,footer", width="100%", cols="m"] |=== @@ -1329,28 +1306,27 @@ Lists all privileges for role `procedureExecutor`: a|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`: +In order to allow the execution of all but only a few procedures, you can grant `EXECUTE PROCEDURES *` and deny the unwanted procedures. +For example, the following queries allow the execution of all procedures, except those starting with `dbms.killTransaction`: -[source, cypher, role=noplay, indent=0] +[source, cypher, role=noplay] ---- GRANT EXECUTE PROCEDURE * ON DBMS TO deniedProcedureExecutor ---- -[source, cypher, role=noplay, indent=0] +[source, cypher, role=noplay] ---- DENY EXECUTE PROCEDURE dbms.killTransaction* ON DBMS TO deniedProcedureExecutor ---- -The resulting role has privileges that only allow executing all procedures except those starting with `dbms.killTransaction`: +The resulting role has privileges that only allow executing all procedures except those starting with `dbms.killTransaction`. +List all privileges for the role `deniedProcedureExecutor` as commands by using the following query: -[source, cypher, role=noplay, indent=0] +[source, cypher, role=noplay] ---- SHOW ROLE deniedProcedureExecutor PRIVILEGES AS COMMANDS ---- -Lists all privileges for role `deniedProcedureExecutor`: - .Result [options="header,footer", width="100%", cols="m"] |=== @@ -1360,34 +1336,35 @@ Lists all privileges for role `deniedProcedureExecutor`: a|Rows: 2 |=== -The `dbms.killTransaction` and `dbms.killTransactions` are blocked, as well as any other procedures starting with `dbms.killTransaction`. +Both `dbms.killTransaction` and `dbms.killTransactions` are blocked here, as well as any other procedures starting with `dbms.killTransaction`. [[access-control-execute-boosted-procedure]] === 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 xref::access-control/dbms-administration.adoc#access-control-name-globbing[name-globbing] without the execution being restricted to their other privileges. +A user with this privilege is allowed to execute the procedures matched by the <> 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: -[source, cypher, role=noplay, indent=0] +[source, cypher, role=noplay] ---- GRANT EXECUTE BOOSTED PROCEDURE db.labels, db.relationshipTypes ON DBMS TO boostedProcedureExecutor ---- -Users with the role `boostedProcedureExecutor` can then run `db.labels` and `db.relationshipTypes` with full privileges, seeing everything in the graph not just the labels and types that the user has `TRAVERSE` privilege on. +Users with the role `boostedProcedureExecutor` can thus run `db.labels` and `db.relationshipTypes` with full privileges. +Now they can see everything on the graph and not just the labels and types that the user has `TRAVERSE` privilege on. -The resulting role has privileges that only allow executing procedures `db.labels` and `db.relationshipTypes`, but with elevated execution: +The resulting role has privileges that only allow executing procedures `db.labels` and `db.relationshipTypes`, but with elevated execution. +List all privileges for the role `boostedProcedureExecutor` as commands by using the following query: -[source, cypher, role=noplay, indent=0] +[source, cypher, role=noplay] ---- SHOW ROLE boostedProcedureExecutor PRIVILEGES AS COMMANDS ---- -Lists all privileges for role `boostedProcedureExecutor`: - .Result [options="header,footer", width="100%", cols="m"] |=== @@ -1397,34 +1374,35 @@ Lists all privileges for role `boostedProcedureExecutor`: a|Rows: 2 |=== -Granting `EXECUTE BOOSTED PROCEDURE` on its own allows the procedure to be both executed (because of the implicit `EXECUTE PROCEDURE` grant) and given elevated privileges during the execution. -A denied `EXECUTE BOOSTED PROCEDURE` on its own behaves slightly differently, and only denies the elevation and not the execution of the procedure. -However, a role with only a granted `EXECUTE BOOSTED PROCEDURE` and a denied `EXECUTE BOOSTED PROCEDURE` will deny the execution as well. +Granting the `EXECUTE BOOSTED PROCEDURE` privilege on its own allows the procedure to be both executed (due to the implicit `EXECUTE PROCEDURE` grant) and proceed with elevated privileges. +A denied `EXECUTE BOOSTED PROCEDURE` on its own behaves slightly differently: it only denies the elevation and not the execution of the procedure. +However, a role with both a granted `EXECUTE BOOSTED PROCEDURE` and a denied `EXECUTE BOOSTED PROCEDURE` will deny the execution as well. This is explained through the following examples: .Grant `EXECUTE PROCEDURE` and deny `EXECUTE BOOSTED PROCEDURE` [example] ==== -[source, cypher, role=noplay, indent=0] +[source, cypher, role=noplay] ---- GRANT EXECUTE PROCEDURE * ON DBMS TO deniedBoostedProcedureExecutor1 ---- -[source, cypher, role=noplay, indent=0] +[source, cypher, role=noplay] ---- DENY EXECUTE BOOSTED PROCEDURE db.labels ON DBMS TO deniedBoostedProcedureExecutor1 ---- -The resulting role has privileges that allow executing all procedures using the user's own privileges, as well as blocking `db.labels` from being elevated. -The deny `EXECUTE BOOSTED PROCEDURE` does not block execution of `db.labels`. +The resulting role has privileges that allow the execution of all procedures using the user's own privileges. +It also prevents `db.labels` from being elevated. +Still, the denied `EXECUTE BOOSTED PROCEDURE` does not block execution of `db.labels`. -[source, cypher, role=noplay, indent=0] +To list all privileges for role `deniedBoostedProcedureExecutor1` as commands, use the following query: + +[source, cypher, role=noplay] ---- SHOW ROLE deniedBoostedProcedureExecutor1 PRIVILEGES AS COMMANDS ---- -Lists all privileges for role `deniedBoostedProcedureExecutor1`: - .Result [options="header,footer", width="100%", cols="m"] |=== @@ -1438,25 +1416,24 @@ a|Rows: 2 .Grant `EXECUTE BOOSTED PROCEDURE` and deny `EXECUTE PROCEDURE` [example] ==== -[source, cypher, role=noplay, indent=0] +[source, cypher, role=noplay] ---- GRANT EXECUTE BOOSTED PROCEDURE * ON DBMS TO deniedBoostedProcedureExecutor2 ---- -[source, cypher, role=noplay, indent=0] +[source, cypher, role=noplay] ---- DENY EXECUTE PROCEDURE db.labels ON DBMS TO deniedBoostedProcedureExecutor2 ---- -The resulting role has privileges that allow executing all procedures with elevated privileges except `db.labels` which is not allowed to execute at all: +The resulting role has privileges that allow executing all procedures with elevated privileges except `db.labels`, which is not allowed to be executed at all. +List all privileges for the role `deniedBoostedProcedureExecutor2` as commands by using the following query: -[source, cypher, role=noplay, indent=0] +[source, cypher, role=noplay] ---- SHOW ROLE deniedBoostedProcedureExecutor2 PRIVILEGES AS COMMANDS ---- -Lists all privileges for role `deniedBoostedProcedureExecutor2`: - .Result [options="header,footer", width="100%", cols="m"] |=== @@ -1470,25 +1447,24 @@ a|Rows: 2 .Grant `EXECUTE BOOSTED PROCEDURE` and deny `EXECUTE BOOSTED PROCEDURE` [example] ==== -[source, cypher, role=noplay, indent=0] +[source, cypher, role=noplay] ---- GRANT EXECUTE BOOSTED PROCEDURE * ON DBMS TO deniedBoostedProcedureExecutor3 ---- -[source, cypher, role=noplay, indent=0] +[source, cypher, role=noplay] ---- DENY EXECUTE BOOSTED PROCEDURE db.labels ON DBMS TO deniedBoostedProcedureExecutor3 ---- -The resulting role has privileges that allow executing all procedures with elevated privileges except `db.labels` which is not allowed to execute at all: +The resulting role has privileges that allow executing all procedures with elevated privileges except `db.labels`, which is not allowed to be executed at all. +List all privileges for the role `deniedBoostedProcedureExecutor3` as commands by using the following query: -[source, cypher, role=noplay, indent=0] +[source, cypher, role=noplay] ---- SHOW ROLE deniedBoostedProcedureExecutor3 PRIVILEGES AS COMMANDS ---- -Lists all privileges for role `deniedBoostedProcedureExecutor3`: - .Result [options="header,footer", width="100%", cols="m"] |=== @@ -1502,24 +1478,25 @@ a|Rows: 2 .Grant `EXECUTE PROCEDURE` and `EXECUTE BOOSTED PROCEDURE` and deny `EXECUTE BOOSTED PROCEDURE` [example] ==== -[source, cypher, role=noplay, indent=0] +[source, cypher, role=noplay] ---- GRANT EXECUTE PROCEDURE db.labels ON DBMS TO deniedBoostedProcedureExecutor4 ---- -[source, cypher, role=noplay, indent=0] +[source, cypher, role=noplay] ---- GRANT EXECUTE BOOSTED PROCEDURE * ON DBMS TO deniedBoostedProcedureExecutor4 ---- -[source, cypher, role=noplay, indent=0] +[source, cypher, role=noplay] ---- DENY EXECUTE BOOSTED PROCEDURE db.labels ON DBMS TO deniedBoostedProcedureExecutor4 ---- -The resulting role has privileges that allow executing all procedures with elevated privileges except `db.labels` which is only allowed to execute using the user's own privileges: +The resulting role has privileges that allow executing all procedures with elevated privileges except `db.labels`, which is only allowed to execute using the user's own privileges. +List all privileges for the role `deniedBoostedProcedureExecutor4` as commands by using the following query: -[source, cypher, role=noplay, indent=0] +[source, cypher, role=noplay] ---- SHOW ROLE deniedBoostedProcedureExecutor4 PRIVILEGES AS COMMANDS ---- @@ -1535,14 +1512,14 @@ a|Rows: 3 |=== ==== -.How would the privileges from Examples 1 to 4 affect the output of a procedure? +.How would the privileges from examples 1 to 4 affect the output of a procedure? [example] ==== -Let's assume there exists a procedure called `myProc`. +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. +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. +Now, adapt the privileges from examples 1 to 4 to be applied to this procedure and show what is returned. With the privileges from example 1, granted `EXECUTE PROCEDURE *` and denied `EXECUTE BOOSTED PROCEDURE myProc`, the `myProc` procedure returns the result `A` and `B`. With the privileges from example 2, granted `EXECUTE BOOSTED PROCEDURE *` and denied `EXECUTE PROCEDURE myProc`, execution of the `myProc` procedure is not allowed. @@ -1551,7 +1528,7 @@ With the privileges from example 3, granted `EXECUTE BOOSTED PROCEDURE *` and de 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. +For comparison, when only `EXECUTE BOOSTED PROCEDURE myProc` is granted, the `myProc` procedure returns the result `A`, `B` and `C`, without the need for granting of the `EXECUTE PROCEDURE myProc` privilege. ==== @@ -1559,26 +1536,25 @@ For comparison, when only granted `EXECUTE BOOSTED PROCEDURE myProc`, the `myPro === 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 xref::access-control/dbms-administration.adoc#access-control-execute-boosted-procedure[`EXECUTE BOOSTED PROCEDURE` privilege] on each of the admin procedures. -Any new admin procedures that gets added are automatically included in this privilege. +This privilege is equivalent to granting the <> 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: -[source, cypher, role=noplay, indent=0] +[source, cypher, role=noplay] ---- GRANT EXECUTE ADMIN PROCEDURES ON DBMS TO adminProcedureExecutor ---- -Users with the role `adminProcedureExecutor` can then run any admin procedure with elevated privileges. +Users with the role `adminProcedureExecutor` can then run any `admin` procedure with elevated privileges. -The resulting role has privileges that allow executing all admin procedures: +The resulting role has privileges that allow executing all admin procedures. +List all privileges for the role `adminProcedureExecutor` as commands by using the following query: -[source, cypher, role=noplay, indent=0] +[source, cypher, role=noplay] ---- SHOW ROLE adminProcedureExecutor PRIVILEGES AS COMMANDS ---- -Lists all privileges for role `adminProcedureExecutor`: - .Result [options="header,footer", width="100%", cols="m"] |=== @@ -1587,15 +1563,14 @@ Lists all privileges for role `adminProcedureExecutor`: a|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. +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. -Let's start with a user only granted the `EXECUTE PROCEDURE myProc` privilege, execution of the `myProc` procedure is not allowed. +By starting with a user only granted with the `EXECUTE PROCEDURE myProc` privilege, execution of the `myProc` procedure is not allowed. -However, for a user granted `EXECUTE BOOSTED PROCEDURE myProc` or `EXECUTE ADMIN PROCEDURES`, the `myProc` procedure returns the result `A`, `B`, and `C`. +However, for a user granted with the `EXECUTE BOOSTED PROCEDURE myProc` or `EXECUTE ADMIN PROCEDURES` privileges, the `myProc` procedure returns the result `A`, `B` and `C`. -Any denied execute privilege results in the procedure not being allowed to execute. -It does not matter whether `EXECUTE PROCEDURE`, `EXECUTE BOOSTED PROCEDURE` or `EXECUTE ADMIN PROCEDURES` is denied. +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. [[access-control-execute-user-defined-function]] @@ -1603,7 +1578,7 @@ It does not matter whether `EXECUTE PROCEDURE`, `EXECUTE BOOSTED PROCEDURE` or ` //EXECUTE [USER [DEFINED]] FUNCTION[S] 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 xref::access-control/dbms-administration.adoc#access-control-name-globbing[name-globbing]. +A user with this privilege is allowed to execute the UDFs matched by the <>. [IMPORTANT] ==== @@ -1614,30 +1589,29 @@ The `EXECUTE USER DEFINED FUNCTION` privilege does not apply to built-in functio ====== The following query shows an example of how to grant this privilege: -[source,cypher,role=noplay, indent=0] +[source,cypher,role=noplay] ---- GRANT EXECUTE USER DEFINED FUNCTION apoc.coll.* ON DBMS TO functionExecutor ---- Or in short form: -[source,cypher,role=noplay, indent=0] +[source,cypher,role=noplay] ---- GRANT EXECUTE FUNCTION apoc.coll.* ON DBMS TO functionExecutor ---- -Users with the role `functionExecutor` can then run any UDF in the `apoc.coll` namespace. -The function is run using the user's own privileges. +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: +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: -[source,cypher,role=noplay, indent=0] +[source,cypher,role=noplay] ---- SHOW ROLE functionExecutor PRIVILEGES AS COMMANDS ---- -Lists all privileges for role `functionExecutor`: - .Result [options="header,footer", width="100%", cols="m"] |=== @@ -1647,43 +1621,42 @@ a|Rows: 1 |=== ====== -If you want to allow executing all but a few UDFs, you can grant `+EXECUTE USER DEFINED FUNCTIONS *+` and deny the unwanted functions. +To allow the execution of all but a few UDFs, you can grant `EXECUTE USER DEFINED FUNCTIONS *` and deny the unwanted functions. .Execute user defined functions ====== -The following queries allow for executing all UDFs except those starting with `apoc.any.prop`: +The following queries allow the execution of all UDFs except those starting with `apoc.any.prop`: -[source, cypher, role=noplay, indent=0] +[source, cypher, role=noplay] ---- GRANT EXECUTE USER DEFINED FUNCTIONS * ON DBMS TO deniedFunctionExecutor ---- -[source, cypher, role=noplay, indent=0] +[source, cypher, role=noplay] ---- DENY EXECUTE USER DEFINED FUNCTION apoc.any.prop* ON DBMS TO deniedFunctionExecutor ---- Or in short form: -[source, cypher, role=noplay, indent=0] +[source, cypher, role=noplay] ---- GRANT EXECUTE FUNCTIONS * ON DBMS TO deniedFunctionExecutor ---- -[source, cypher, role=noplay, indent=0] +[source, cypher, role=noplay] ---- DENY EXECUTE FUNCTION apoc.any.prop* ON DBMS TO deniedFunctionExecutor ---- -The resulting role has privileges that only allow executing all procedures except those starting with `apoc.any.prop`: +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: -[source, cypher, role=noplay, indent=0] +[source, cypher, role=noplay] ---- SHOW ROLE deniedFunctionExecutor PRIVILEGES AS COMMANDS ---- -Lists all privileges for role `deniedFunctionExecutor`: - .Result [options="header,footer", width="100%", cols="m"] |=== @@ -1693,7 +1666,7 @@ Lists all privileges for role `deniedFunctionExecutor`: a|Rows: 2 |=== -The `apoc.any.property` and `apoc.any.properties` is blocked, as well as any other procedures starting with `apoc.any.prop`. +The `apoc.any.property` and `apoc.any.properties` are blocked, as well as any other procedures starting with `apoc.any.prop`. ====== [[access-control-execute-boosted-user-defined-function]] @@ -1701,47 +1674,47 @@ The `apoc.any.property` and `apoc.any.properties` is blocked, as well as any oth //EXECUTE BOOSTED [USER [DEFINED]] FUNCTION[S] 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 xref::access-control/dbms-administration.adoc#access-control-name-globbing[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. +A user with this privilege is allowed to execute the UDFs matched by the <> without the execution being restricted to their other privileges. + +There is no need to grant an individual `EXECUTE USER DEFINED FUNCTION` privilege for the functions, as granting `EXECUTE BOOSTED USER DEFINED FUNCTION` includes an implicit `EXECUTE USER DEFINED FUNCTION` grant. +However, a denied `EXECUTE USER DEFINED FUNCTION` still prevents the function to be executed. [IMPORTANT] ==== The `EXECUTE BOOSTED USER DEFINED FUNCTION` privilege does not apply to built-in functions, as they have no concept of elevated privileges. ==== -Granting `EXECUTE BOOSTED USER DEFINED FUNCTION` on its own allows the UDF to be both executed (because of the implicit `EXECUTE USER DEFINED FUNCTION` grant) and given elevated privileges during the execution. -A denied `EXECUTE BOOSTED USER DEFINED FUNCTION` on its own behaves slightly differently, and only denies the elevation and not the execution of the UDF. -However, a role with only a granted `EXECUTE BOOSTED USER DEFINED FUNCTION` and a denied `EXECUTE BOOSTED USER DEFINED FUNCTION` denies the execution as well. -This is the same behavior as for the xref::access-control/dbms-administration.adoc#access-control-execute-boosted-procedure[`EXECUTE BOOSTED PROCEDURE` privilege]. +Granting `EXECUTE BOOSTED USER DEFINED FUNCTION` on its own allows the UDF to be both executed (because of the implicit `EXECUTE USER DEFINED FUNCTION` grant) and gives it elevated privileges during the execution. +A denied `EXECUTE BOOSTED USER DEFINED FUNCTION` on its own behaves slightly differently: it only denies the elevation and not the execution of the UDF. +However, a role with only a granted `EXECUTE BOOSTED USER DEFINED FUNCTION` and a denied `EXECUTE BOOSTED USER DEFINED FUNCTION` prevents the execution to be performed as well. +This is the same behavior as for the <>. .Execute boosted user defined function ====== The following query shows an example of how to grant the `EXECUTE BOOSTED USER DEFINED FUNCTION` privilege: -[source,cypher,role=noplay, indent=0] +[source,cypher,role=noplay] ---- GRANT EXECUTE BOOSTED USER DEFINED FUNCTION apoc.any.properties ON DBMS TO boostedFunctionExecutor ---- Or in short form: -[source,cypher,role=noplay, indent=0] +[source,cypher,role=noplay] ---- GRANT EXECUTE BOOSTED FUNCTION apoc.any.properties ON DBMS TO boostedFunctionExecutor ---- -Users with the role `boostedFunctionExecutor` can then run `apoc.any.properties` with full privileges, seeing every property on the node/relationship not just the properties that the user has `READ` privilege on. +Users with the role `boostedFunctionExecutor` can thus run `apoc.any.properties` with full privileges and see every property on the node/relationship, not just the properties that the user has `READ` privilege on. -The resulting role has privileges that only allow executing the UDF `apoc.any.properties`, but with elevated execution: +The resulting role has privileges that only allow executing of the UDF `apoc.any.properties`, but with elevated execution. +List all privileges for the role `boostedFunctionExecutor` as commands by using the following query: -[source,cypher,role=noplay, indent=0] +[source,cypher,role=noplay] ---- SHOW ROLE boostedFunctionExecutor PRIVILEGES AS COMMANDS ---- -Lists all privileges for role `boostedFunctionExecutor`: - .Result [options="header,footer",width="100%",cols="m"] |=== @@ -1754,20 +1727,21 @@ a|Rows: 1 [[access-control-name-globbing]] === 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 for procedure and user defined function names is a simplified version of globbing for filename expansions. +It only allows two wildcard characters: `+*+` and `?`, which are used for multiple and single character matches. +In this case, `+*+` means 0 or more characters and `?` matches exactly one character. [NOTE] ==== -The name-globbing is subject to the xref::syntax/naming.adoc[standard Cypher restrictions on valid identifiers], +The name-globbing is subject to the <>, 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. +It is also good to keep in mind that wildcard characters behave as wildcards even when escaped. As an example, using `++`*`++` is equivalent to using `+*+`, and thus allows executing all functions or procedures and not only the procedure or function named `+*+`. ==== -The examples below only use procedures but the same rules apply to user defined function names. -For the examples below, assume we have the following procedures: +The examples below only use procedures, but the same rules apply to user defined function names: * `mine.public.exampleProcedure` * `mine.public.exampleProcedure1` @@ -1779,51 +1753,51 @@ For the examples below, assume we have the following procedures: * `mine.private.with#Special§Characters` * `your.exampleProcedure` -[source, cypher, role=noplay, indent=0] +[source, cypher, role=noplay] ---- GRANT EXECUTE PROCEDURE * ON DBMS TO globbing1 ---- -Users with the role `globbing1` can then run procedures all the procedures. +Users with the role `globbing1` can thus run all the procedures. -[source, cypher, role=noplay, indent=0] +[source, cypher, role=noplay] ---- GRANT EXECUTE PROCEDURE mine.*.exampleProcedure ON DBMS TO globbing2 ---- -Users with the role `globbing2` can then run procedures `mine.public.exampleProcedure` and `mine.private.exampleProcedure`, but none of the others. +Users with the role `globbing2` can thus run procedures `mine.public.exampleProcedure` and `mine.private.exampleProcedure`, but none of the others. -[source, cypher, role=noplay, indent=0] +[source, cypher, role=noplay] ---- GRANT EXECUTE PROCEDURE mine.*.exampleProcedure? ON DBMS TO globbing3 ---- -Users with the role `globbing3` can then run procedures `mine.public.exampleProcedure1`, `mine.private.exampleProcedure1` and `mine.private.exampleProcedure2`, but none of the others. +Users with the role `globbing3` can thus run procedures `mine.public.exampleProcedure1`, `mine.private.exampleProcedure1` and `mine.private.exampleProcedure2`, but none of the others. -[source, cypher, role=noplay, indent=0] +[source, cypher, role=noplay] ---- GRANT EXECUTE PROCEDURE *.exampleProcedure ON DBMS TO globbing4 ---- -Users with the role `globbing4` can then run procedures `your.exampleProcedure`, `mine.public.exampleProcedure` and `mine.private.exampleProcedure`, but none of the others. +Users with the role `globbing4` can thus run procedures `your.exampleProcedure`, `mine.public.exampleProcedure` and `mine.private.exampleProcedure`, but none of the others. -[source, cypher, role=noplay, indent=0] +[source, cypher, role=noplay] ---- GRANT EXECUTE PROCEDURE mine.public.exampleProcedure* ON DBMS TO globbing5 ---- -Users with the role `globbing5` can then run procedures `mine.public.exampleProcedure`, `mine.public.exampleProcedure1` and `mine.public.exampleProcedure42`, but none of the others. +Users with the role `globbing5` can thus run procedures `mine.public.exampleProcedure`, `mine.public.exampleProcedure1` and `mine.public.exampleProcedure42`, but none of the others. -[source, cypher, role=noplay, indent=0] +[source, cypher, role=noplay] ---- GRANT EXECUTE PROCEDURE `mine.public.with#*§Characters`, mine.private.`with#Spec???§Characters` ON DBMS TO globbing6 ---- -Users with the role `globbing6` can then run procedures `mine.public.with#Special§Characters` and `mine.private.with#Special§Characters`, but none of the others. +Users with the role `globbing6` can thus run procedures `mine.public.with#Special§Characters` and `mine.private.with#Special§Characters`, but none of the others. [NOTE] ==== -The name-globbing may be fully or partially escaped, and both the `+*+` and `+?+` are interpreted as wildcards either way. +The name-globbing may be fully or partially escaped. Both `+*+` and `+?+` are interpreted as wildcards either way. ==== @@ -1832,42 +1806,30 @@ The name-globbing may be fully or partially escaped, and both the `+*+` and `+?+ 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 -* impersonate users -* create databases -* alter databases -* drop databases -* show privileges -* assign privileges -* remove privileges -* execute all procedures with elevated privileges -* execute all user defined functions with elevated privileges - -[source, cypher, role=noplay, indent=0] +* Create, drop, assign, remove and show roles +* Create, alter, drop, show and impersonate users +* Create, alter and drop databases +* Show, assign and remove privileges +* Execute all procedures with elevated privileges +* Execute all user defined functions with elevated privileges + +[source, cypher, role=noplay] ---- GRANT ALL [[DBMS] PRIVILEGES] ON DBMS TO role[, ...] ---- -For example, granting the abilities above to the role `dbmsManager` is done using the following query. +For example, to grant the role `dbmsManager` the abilities above, use the following query: -[source, cypher, role=noplay, indent=0] +[source, cypher, role=noplay] ---- GRANT ALL DBMS PRIVILEGES ON DBMS TO dbmsManager ---- The privileges granted can be seen using the `SHOW PRIVILEGES` command: -[source, cypher, role=noplay, indent=0] +[source, cypher, role=noplay] ---- SHOW ROLE dbmsManager PRIVILEGES AS COMMANDS ---- @@ -1879,4 +1841,3 @@ SHOW ROLE dbmsManager PRIVILEGES AS COMMANDS |"GRANT ALL DBMS PRIVILEGES ON DBMS TO `dbmsManager`" a|Rows: 1 |=== - diff --git a/modules/ROOT/pages/access-control/index.adoc b/modules/ROOT/pages/access-control/index.adoc index e9d31ec42..81cc9d1c0 100644 --- a/modules/ROOT/pages/access-control/index.adoc +++ b/modules/ROOT/pages/access-control/index.adoc @@ -1,38 +1,35 @@ -:description: Neo4j role-based access control and fine-grained security. - [[access-control]] = Access control [abstract] -- -This section explains how to manage Neo4j role-based access control and fine-grained security. +This chapter explains how to manage Neo4j role-based access control and fine-grained security. -- -Neo4j has a complex security model stored in the system graph, maintained in a special database called the `system` database. -All administrative commands need to be executing against the `system` database. -When connected to the DBMS over bolt, administrative commands are automatically routed to the `system` database. -For more information on how to manage multiple databases, refer to the section on xref::databases.adoc[administering databases]. +Neo4j has a complex security model stored in the system graph, which is maintained on a special database called the `system` database. +All administrative commands need to be executed against the `system` database. +When connected to the DBMS over `bolt`, administrative commands are automatically routed to the `system` database. +For more information on how to manage multiple databases, refer to the section on <>. -Neo4j 3.1 introduced the concept of _role-based access control_. -It was possible to create users and assign them to roles to control whether the users could read, write and administer the database. +The concept of _role-based access control_ was introduced in Neo4j 3.1. +Since then, it has been possible to create users and assign them to roles to control whether users can read, write and administer the database. In Neo4j 4.0 this model was enhanced significantly with the addition of _privileges_, which are the underlying access-control rules by which the users rights are defined. -The original built-in roles still exist with almost the exact same access rights, but they are no-longer statically defined (see xref::access-control/built-in-roles.adoc[Built-in roles]). +The original built-in roles still exist with almost the exact same access rights, but they are no-longer statically defined (see <>). Instead they are defined in terms of their underlying _privileges_ and they can be modified by adding an removing these access rights. -In addition, any new roles created can by assigned any combination of _privileges_ to create the specific access control desired. -A major additional capability is _sub-graph_ access control whereby read-access to the graph can be limited to specific combinations of label, relationship-type and property. +In addition, any new roles can be assigned to any combination of _privileges_ to create specific access controls. +Another new major capability is the _sub-graph_ access control, through which read access to the graph can be limited to specific combinations of labels, relationship types, and properties. [[access-control-syntax]] == Syntax summaries -Almost all administration commands have variations in the commands. -Parts of the command that are optional or can have multiple values are most common. -To show all versions of a command, a summary of the syntax will be presented. -These summaries will use some special characters to indicate such variations. +Almost all administration commands have variations. +The most common are parts of the command that are optional or that can have multiple values. -The special characters and their meaning are as follows: +See below a summary of the syntax to check all versions of a command. +These summaries use some special characters to indicate such variations. .Special characters in syntax summaries [options="header", width="100%", cols="1a,3a,3a"] @@ -40,13 +37,14 @@ The special characters and their meaning are as follows: | Character | Meaning | Example | `\|` -| Or, used to indicate alternative parts of a command. +| Or. +Used to indicate alternative parts of a command. Needs to be part of a grouping. -| If the syntax needs to specify either a name or `+*+`, this can be indicated with `+* \| name+`. +| If the syntax needs to specify either a name or `+*+`, this can be indicated with `* \| name`. -| `+{+` and `+}+` -| Used to group parts of the command, common together with `\|`. -| To use the `or` in the syntax summary it needs to be in a group, `+{* \| name}+`. +| `{` and `}` +| Used to group parts of the command. Commonly found together with `\|`. +| In order to use the `or` in the syntax summary, it needs to be in a group: `{* \| name}`. | `[` and `]` | Used to indicate an optional part of the command. @@ -54,40 +52,60 @@ It also groups alternatives together, when there can be either of the alternativ | If a keyword in the syntax can either be in singular or plural, we can indicate that the `S` is optional with `GRAPH[S]`. | `...` -| Repeated pattern, the command part immediately before this is repeated. -| A comma separated list of names would be `+name[, ...]+`. +| Repeated pattern. +Related to the command part immediately before this is repeated. +| A comma separated list of names would be `name[, ...]`. | `"` | When a special character is part of the syntax itself, we surround it with `"` to indicate this. -| To include `+{+` in the syntax use `+"{" { * \| name } "}"+`, here we get either `+{*}+` or `+{name}+`. +| To include `{` in the syntax use `"{" { * \| name } "}"`. In this case, you will get either `{*}` or `{name}`. |=== The special characters in the table above are the only ones that need to be escaped using `"` in the syntax summaries. -An example that uses all special characters is granting the `READ` privilege: +Here is an example that uses all special characters is granting the `READ` privilege: -[source, syntax, role="noheader"] +[source, cypher, role=noplay] ---- GRANT READ - "{" { * | property[, ...] } "}" - ON {HOME GRAPH | GRAPH[S] { * | name[, ...] }} - [ ELEMENT[S] { * | label-or-rel-type[, ...] } - | NODE[S] { * | label[, ...] } - | RELATIONSHIP[S] { * | rel-type[, ...] }] - TO role[, ...] + "{" { * | property[, ...] } "}" + ON {HOME GRAPH | GRAPH[S] { * | name[, ...] }} + [ + ELEMENT[S] { * | label-or-rel-type[, ...] } + | NODE[S] { * | label[, ...] } + | RELATIONSHIP[S] { * | rel-type[, ...] } + ] + TO role[, ...] ---- -Some things to notice about this command is that it includes `+{+` and `+}+` in the syntax, and between them has a grouping of either a list of properties or the character `+*+`. +Note that this command includes `{` and `}` in the syntax, and between them there can be a grouping of properties or the character `*`. It also has multiple optional parts, including the entity part of the command which is the grouping following the graph name. -In difference, there is no need to escape any characters in the node property existence constraint creation command. -This is because `(` and `)` are not special characters, and the `[` and `]` indicate that the constraint name is optional, and are not part of the command. +However, there is no need to escape any characters when creating a constraint for a node property. +This is because `(` and `)` are not special characters, and `[` and `]` indicate that the constraint name is optional, and therefore not part of the command. -[source, syntax, role="noheader", indent=0] +[source, cypher, role=noplay] ---- CREATE CONSTRAINT [constraint_name] [IF NOT EXISTS] FOR (n:LabelName) REQUIRE n.propertyName IS NOT NULL ---- +include::manage-users.adoc[leveloffset=+1] + +include::manage-roles.adoc[leveloffset=+1] + +include::manage-privileges.adoc[leveloffset=+1] + +include::built-in-roles.adoc[leveloffset=+1] + +include::privileges-read.adoc[leveloffset=+1] + +include::privileges-write.adoc[leveloffset=+1] + +include::database-administration.adoc[leveloffset=+1] + +include::dbms-administration.adoc[leveloffset=+1] + +include::limitations.adoc[leveloffset=+1] diff --git a/modules/ROOT/pages/access-control/limitations.adoc b/modules/ROOT/pages/access-control/limitations.adoc index 28f30e22c..be0528a90 100644 --- a/modules/ROOT/pages/access-control/limitations.adoc +++ b/modules/ROOT/pages/access-control/limitations.adoc @@ -1,174 +1,166 @@ -:description: Known limitations and implications of Neo4js role-based access control security. - [[access-control-limitations]] = Limitations [abstract] -- -This section explains known limitations and implications of Neo4js role-based access control security. +This section lists the known limitations and implications of Neo4js role-based access control security. -- [[access-control-limitations-indexes]] == Security and Indexes -As described in xref::indexes-for-search-performance.adoc[Indexes for search performance], Neo4j {neo4j-version} supports the creation and use of indexes to improve the performance of Cypher queries. -The Neo4j security model will impact the results of queries (regardless if the indexes are used). +As described in <>, Neo4j {neo4j-version} supports the creation and use of indexes to improve the performance of Cypher queries. + +Note that the Neo4j security model impacts the results of queries, regardless if the indexes are used or not. When using non full-text Neo4j indexes, a Cypher query will always return the same results it would have if no index existed. -This means that if the security model causes fewer results to be returned due to restricted read access in xref::access-control/manage-privileges.adoc[Graph and sub-graph access control], the index will also return the same fewer results. +This means that, if the security model causes fewer results to be returned due to restricted read access in <>, +the index will also return the same fewer results. -However, this rule is not fully obeyed by xref::indexes-for-full-text-search.adoc[Indexes for full-text search]. -These specific indexes are backed by Lucene internally. -It is therefore not possible to know for certain whether a security violation occurred for each specific entry returned from the index. -As a result, Neo4j will return zero results from full-text indexes if it is determined that any result might violate the security privileges active for that query. +However, this rule is not fully obeyed by <>. +These specific indexes are backed by _Lucene_ internally. +It is therefore not possible to know for certain whether a security violation has affected each specific entry returned from the index. +In face of this, Neo4j will return zero results from full-text indexes in case it is determined that any result might be violating the security privileges active for that query. -Since full-text indexes are not automatically used by Cypher, this does not lead to the case where the same Cypher query would return different results simply because such an index got created. +Since full-text indexes are not automatically used by Cypher, they do not lead to the case where the same Cypher query would return different results simply because such an index was created. Users need to explicitly call procedures to use these indexes. -The problem is only that if this behavior is not understood by the user, they might expect the full text index to return the same results that a different, but semantically similar, Cypher query does. +The problem is only that, if this behavior is not known by the user, they might expect the full-text index to return the same results that a different, but semantically similar, Cypher query does. === Example with denied properties Consider the following example. -The database has nodes with labels `:User` and `:Person`, and these have properties `name` and `surname`. -We have indexes on both properties: +The database has nodes with labels `:User` and `:Person`, and they have properties `name` and `surname`. +There are indexes on both properties: -[source, cypher, indent=0] +[source, cypher] ---- -CREATE INDEX singleProp FOR (n:User) ON (n.name) -CREATE INDEX composite FOR (n:User) ON (n.name, n.surname) -CREATE FULLTEXT INDEX userNames FOR (n:User|Person) ON EACH [n.name, n.surname] +CREATE INDEX singleProp FOR (n:User) ON (n.name); +CREATE INDEX composite FOR (n:User) ON (n.name, n.surname); +CREATE FULLTEXT INDEX userNames FOR (n:User|Person) ON EACH [n.name, n.surname]; ---- [NOTE] -==== Full-text indexes support multiple labels. -See xref::indexes-for-full-text-search.adoc[Indexes for full-text search] for more details on creating and using full-text indexes. -==== +See <> for more details on creating and using full-text indexes. After creating these indexes, it would appear that the latter two indexes accomplish the same thing. However, this is not completely accurate. -The composite and fulltext indexes behave in different ways and are focused on different use cases. -A key difference is that full-text indexes are backed by Lucene, and will use the Lucene syntax for querying the index. +The composite and full-text indexes behave in different ways and are focused on different use cases. +A key difference is that full-text indexes are backed by _Lucene_, and will use the _Lucene_ syntax for querying. This has consequences for users restricted on the labels or properties involved in the indexes. -Ideally, if the labels and properties in the index are denied, we can correctly return zero results from both native indexes and full-text indexes. +Ideally, if the labels and properties in the index are denied, they can correctly return zero results from both native indexes and full-text indexes. However, there are borderline cases where this is not as simple. Imagine the following nodes were added to the database: -[source, cypher, indent=0] +[source, cypher] ---- -CREATE (:User {name: 'Sandy'}) -CREATE (:User {name: 'Mark', surname: 'Andy'}) -CREATE (:User {name: 'Andy', surname: 'Anderson'}) -CREATE (:User:Person {name: 'Mandy', surname: 'Smith'}) -CREATE (:User:Person {name: 'Joe', surname: 'Andy'}) +CREATE (:User {name:'Sandy'}); +CREATE (:User {name:'Mark', surname:'Andy'}); +CREATE (:User {name:'Andy', surname:'Anderson'}); +CREATE (:User:Person {name:'Mandy', surname:'Smith'}); +CREATE (:User:Person {name:'Joe', surname:'Andy'}); ---- -Consider denying the label `:Person`. +Consider denying the label `:Person`: -[source, cypher, indent=0] +[source, cypher] ---- -DENY TRAVERSE Person ON GRAPH * TO users +DENY TRAVERSE Person ON GRAPH * TO users; ---- If the user runs a query that uses the native single property index on `name`: -[source, cypher, indent=0] +[source, cypher] ---- -MATCH (n:User) WHERE n.name CONTAINS 'ndy' RETURN n.name +MATCH (n:User) WHERE n.name CONTAINS 'ndy' RETURN n.name; ---- This query performs several checks: -* do a scan on the index to create a stream of results of nodes with the `name` property, which leads to five results -* filter the results to include only nodes where `n.name CONTAINS 'ndy'`, filtering out `Mark` and `Joe` so we have three results -* filter the results to exclude nodes that also have the denied label `:Person`, filtering out `Mandy` so we have two results +* Scans the index to create a stream of results of nodes with the `name` property, which leads to five results. +* Filters the results to include only nodes where `n.name CONTAINS 'ndy'`, filtering out `Mark` and `Joe`, which leads to three results. +* Filters the results to exclude nodes that also have the denied label `:Person`, filtering out `Mandy`, which leads to two results. -For the above dataset, we can see we will get two results and that only one of these has the `surname` property. +Two results will be returned from this dataset and only one of them has the `surname` property. -To use the native composite index on `name` and `surname`, the query needs to include a predicate on the `surname` property as well: +In order to use the native composite index on `name` and `surname`, the query needs to include a predicate on the `surname` property as well: -[source, cypher, indent=0] +[source, cypher] ---- -MATCH (n:User) -WHERE n.name CONTAINS 'ndy' AND n.surname IS NOT NULL -RETURN n.name +MATCH (n:User) WHERE n.name CONTAINS 'ndy' AND n.surname IS NOT NULL RETURN n.name; ---- -This query performs several checks, almost identical to the single property index query: - -* do a scan on the index to create a stream of results of nodes with the `name` and `surname` property, which leads to four results -* filter the results to include only nodes where `n.name CONTAINS 'ndy'`, filtering out `Mark` and `Joe` so we have two results -* filter the results to exclude nodes that also have the denied label `:Person`, filtering out `Mandy` so we only have one result +This query performs several checks, which are almost identical to the single property index query: -For the above dataset, we can see we will get one result. +* Scans the index to create a stream of results of nodes with the `name` and `surname` property, which leads to four results. +* Filters the results to include only nodes where `n.name CONTAINS 'ndy'`, filtering out `Mark` and `Joe`, which leads to two results. +* Filters the results to exclude nodes that also have the denied label `:Person`, filtering out `Mandy`, which leads to only one result. -What if we query this with the full-text index: +Only one result was returned from the above dataset. +What if this query with the full-text index was used instead: -[source, cypher, indent=0] +[source, cypher] ---- CALL db.index.fulltext.queryNodes("userNames", "ndy") YIELD node, score RETURN node.name ---- -The problem now is that we do not know if the results provided by the index were because of a match to the `name` or the `surname` property. +The problem now is that it is not certain whether the results provided by the index were achieved due to a match to the `name` or the `surname` property. The steps taken by the query engine would be: -* run a _Lucene_ query on the full-text index to produce results containing `ndy` in either property, leading to five results. -* filter the results to exclude nodes that also have the label `:Person`, filtering out `Mandy` and `Joe` so we have three results. +* Run a _Lucene_ query on the full-text index to produce results containing `ndy` in either property, leading to five results. +* Filter the results to exclude nodes that also have the label `:Person`, filtering out `Mandy` and `Joe`, leading to three results. -This difference in results is due to the `OR` relationship between the two properties in the index creation. +This difference in results is caused by the `OR` relationship between the two properties in the index creation. === Denying properties Now consider denying access on properties, like the `surname` property: -[source, cypher, indent=0] +[source, cypher] ---- -DENY READ {surname} ON GRAPH * TO users +DENY READ {surname} ON GRAPH * TO users; ---- -Now we run the same queries again: +For that, run the same queries again: -[source, cypher, indent=0] +[source, cypher] ---- -MATCH (n:User) -WHERE n.name CONTAINS 'ndy' -RETURN n.name +MATCH (n:User) WHERE n.name CONTAINS 'ndy' RETURN n.name; ---- -This query operates exactly as before, returning the same two results, because nothing in this query relates to the denied property. +This query operates exactly as before, returning the same two results, because nothing in it relates to the denied property. -However, for the query targeting the composite index, things have changed. +However, this is not the same for the query targeting the composite index: -[source, cypher, indent=0] +[source, cypher] ---- -MATCH (n:User) -WHERE n.name CONTAINS 'ndy' AND n.surname IS NOT NULL -RETURN n.name +MATCH (n:User) WHERE n.name CONTAINS 'ndy' AND n.surname IS NOT NULL RETURN n.name; ---- Since the `surname` property is denied, it will appear to always be `null` and the composite index empty. Therefore, the query returns no result. Now consider the full-text index query: -[source, cypher, indent=0] +[source, cypher] ---- CALL db.index.fulltext.queryNodes("userNames", "ndy") YIELD node, score RETURN node.name ---- -The problem remains, we do not know if the results provided by the index were because of a match on the `name` or the `surname` property. -Results from the surname now need to be excluded by the security rules, because they require that the user cannot see any `surname` properties. -However, the security model is not able to introspect the _Lucene_ query to know what it will actually do, whether it works only on the allowed `name` property, or also on the disallowed `surname` property. -We know that the earlier query returned a match for `Joe Andy` which should now be filtered out. -So, in order to never return results the user should not be able to see, we have to block all results. +The problem remains, since it is not certain whether the results provided by the index were returned due to a match on the `name` or the `surname` property. +Results from the `surname` property now need to be excluded by the security rules, because they require that the user is unable to see any `surname` properties. +However, the security model is not able to introspect the _Lucene_ query in order to know what it will actually do, whether it works only on the allowed `name` property, or also on the disallowed `surname` property. +What is known is that the earlier query returned a match for `Joe Andy` which should now be filtered out. +Therefore, in order to never return results the user should not be able to see, all results need to be blocked. The steps taken by the query engine would be: -* Determine if the full-text index includes denied properties -* If yes, return an empty results stream, otherwise process as before +* Determine if the full-text index includes denied properties. +* If yes, return an empty results stream. +Otherwise, it will process as described before. -The query will therefore return zero results in this case, rather than simply returning the results `Andy` and `Sandy` which might be expected. +In this case, the query will return zero results rather than simply returning the results `Andy` and `Sandy`, which might have been expected. [[access-control-limitations-labels]] @@ -176,121 +168,116 @@ The query will therefore return zero results in this case, rather than simply re === Traversing the graph with multi-labeled nodes -The general influence of access control privileges on graph traversal is described in detail in xref::access-control/manage-privileges.adoc[Graph and sub-graph access control]. -The following section will only focus on nodes because of their ability to have multiple labels. Relationships can only ever have one type -and thus they do not exhibit the behavior this section aims to clarify. +The general influence of access control privileges on graph traversal is described in detail in <>. +The following section will only focus on nodes due to their ability to have multiple labels. +Relationships can only have one type of label and thus they do not exhibit the behavior this section aims to clarify. While this section will not mention relationships further, the general function of the traverse privilege also applies to them. -For any node that is traversable, due to `GRANT TRAVERSE` or `GRANT MATCH`, the user can get information about the labels attached to the node by calling the built-in `labels()` function. -In the case of nodes with multiple labels, this can seemingly result in labels being returned to which the user was not directly granted access to. +For any node that is traversable, due to `GRANT TRAVERSE` or `GRANT MATCH`, +the user can get information about the attached labels by calling the built-in `labels()` function. +In the case of nodes with multiple labels, they can be returned to users that weren't directly granted access to. -To give an illustrative example, imagine a graph with three nodes: one labeled `:A`, one labeled `:B` and one with `:A :B`. -We also have a user with a role `custom` as defined by: +To give an illustrative example, imagine a graph with three nodes: one labeled `:A`, another labeled `:B` and one with the labels `:A` and `:B`. +In this case, there is a user with the role `custom` defined by: -[source, cypher, indent=0] +[source, cypher] ---- -GRANT TRAVERSE ON GRAPH * NODES A TO custom +GRANT TRAVERSE ON GRAPH * NODES A TO custom; ---- If that user were to execute -[source, cypher, indent=0] +[source, cypher] ---- -MATCH (n:A) -RETURN n, labels(n) +MATCH (n:A) RETURN n, labels(n); ---- -they would be returned two nodes: the node that was labeled with `:A` and the node with labels `:A :B`. +They would get a result with two nodes: the node that was labeled with `:A` and the node with labels `:A :B`. In contrast, executing -[source, cypher, indent=0] +[source, cypher] ---- -MATCH (n:B) -RETURN n, labels(n) +MATCH (n:B) RETURN n, labels(n); ---- -will return only the one node that has both labels: `:A :B`. Even though `:B` was not allowed access for traversal, there is one -node with that label accessible in the data because of the allowlisted label `:A` that is attached to the same node. +This will return only the one node that has both labels: `:A` and `:B`. +Even though `:B` did not have access to traversals, there is one node with that label accessible in the dataset due to the allow-listed label `:A` that is attached to the same node. -If a user is denied traverse on a label they will never get results from any node that has this label -attached to it. Thus, the label name will never show up for them. For our example this can be done by executing: +If a user is denied to traverse on a label they will never get results from any node that has this label attached to it. +Thus, the label name will never show up for them. +As an example, this can be done by executing: -[source, cypher, indent=0] +[source, cypher] ---- -DENY TRAVERSE ON GRAPH * NODES B TO custom +DENY TRAVERSE ON GRAPH * NODES B TO custom; ---- The query -[source, cypher, indent=0] +[source, cypher] ---- -MATCH (n:A) -RETURN n, labels(n) +MATCH (n:A) RETURN n, labels(n); ---- will now return the node only labeled with `:A`, while the query -[source, cypher, indent=0] +[source, cypher] ---- -MATCH (n:B) -RETURN n, labels(n) +MATCH (n:B) RETURN n, labels(n); ---- will now return no nodes. === The db.labels() procedure -In contrast to the normal graph traversal described in the previous section, the built-in `db.labels()` procedure is not processing the data graph itself but the security rules defined on the system graph. +In contrast to the normal graph traversal described in the previous section, the built-in `db.labels()` procedure +is not processing the data graph itself, but the security rules defined on the system graph. That means: -* if a label is explicitly whitelisted (granted), it will be returned by this procedure. -* if a label is denied or isn't explicitly allowed it will not be returned by this procedure. +* If a label is explicitly whitelisted (granted), it will be returned by this procedure. +* If a label is denied or isn't explicitly allowed, it will not be returned by this procedure. -To reuse the example of the previous section: imagine a graph with three nodes: one labeled `:A`, one labeled `:B` and one with `:A :B`. -We also have a user with a role `custom` as defined by: +Reusing the previous example, imagine a graph with three nodes: one labeled `:A`, another labeled `:B` and one with the labels `:A` and `:B`. +In this case, there is a user with the role `custom` defined by: -[source, cypher, indent=0] +[source, cypher] ---- -GRANT TRAVERSE ON GRAPH * NODES A TO custom +GRANT TRAVERSE ON GRAPH * NODES A TO custom; ---- -This means that only label `:A` is explicitly allowlisted. +This means that only label `:A` is explicitly allow-listed. Thus, executing -[source, cypher, indent=0] +[source, cypher] ---- -CALL db.labels() +CALL db.labels(); ---- -will only return label `:A` because that is the only label for which traversal was granted. +will only return label `:A`, because that is the only label for which traversal was granted. [[access-control-limitations-db-operations]] == Security and count store operations The rules of a security model may impact some of the database operations. -This comes down to necessary additional security checks that incur additional data accesses. -Especially in regards to count store operations, as they are usually very fast lookups, the difference might be noticeable. +This means extra security checks are necessary to incur additional data accesses, especially in the case of count store operations. +These are, however, usually very fast lookups and the difference might be noticeable. -Let's look at the following security rules that set up a `restricted` and a `free` role as an example: +See the following security rules that set up a `restricted` and a `free` role as an example: ----- -GRANT TRAVERSE ON GRAPH * NODES Person TO restricted -DENY TRAVERSE ON GRAPH * NODES Customer TO restricted -GRANT TRAVERSE ON GRAPH * ELEMENTS * TO free ----- + GRANT TRAVERSE ON GRAPH * NODES Person TO restricted; + DENY TRAVERSE ON GRAPH * NODES Customer TO restricted; + GRANT TRAVERSE ON GRAPH * ELEMENTS * TO free; Now, let's look at what the database needs to do in order to execute the following query: ----- -MATCH (n:Person) -RETURN count(n) ----- + MATCH (n:Person) RETURN count(n); For both roles the execution plan will look like this: ----- +[listing] +.... +--------------------------+ | Operator | +--------------------------+ @@ -298,25 +285,23 @@ For both roles the execution plan will look like this: | | + | +NodeCountFromCountStore | +--------------------------+ ----- +.... -Internally however, very different operations need to be executed. -The following table illustrates the difference. +Internally, however, very different operations need to be executed. +The following table illustrates the difference: [%header,cols=2*] |=== -| User with `free` role | User with `restricted` role +|User with `free` role +|User with `restricted` role -a| -The database can access the count store and retrieve the total number of nodes with the label `:Person`. +|The database can access the count store and retrieve the total number of nodes with the label `:Person`. This is a very quick operation. -a| -The database cannot just access the count store because it must make sure that only traversable nodes with the desired label `:Person` are counted. -Due to this, each node with the `:Person` label needs to be accessed and examined to make sure that it does not also have a denylisted label, such as `:Customer`. +|The database cannot access the count store because it must make sure that only traversable nodes with the desired label `:Person` are counted. +Due to this, each node with the `:Person` label needs to be accessed and examined to make sure that they do not have a deny-listed label, such as `:Customer`. Due to the additional data accesses that the security checks need to do, this operation will be slower compared to executing the query as an unrestricted user. |=== - diff --git a/modules/ROOT/pages/access-control/manage-privileges.adoc b/modules/ROOT/pages/access-control/manage-privileges.adoc index 633232291..2b5f84b5d 100644 --- a/modules/ROOT/pages/access-control/manage-privileges.adoc +++ b/modules/ROOT/pages/access-control/manage-privileges.adoc @@ -1,6 +1,4 @@ -:description: This section explains how to use Cypher to manage privileges for Neo4j role-based access control and fine-grained security. [[access-control-manage-privileges]] - = Managing privileges [abstract] @@ -9,32 +7,32 @@ This section explains how to use Cypher to manage privileges for Neo4j role-base -- Privileges control the access rights to graph elements using a combined allowlist/denylist mechanism. -It is possible to grant access, or deny access, or a combination of the two. -The user will be able to access the resource if they have a grant (whitelist) and do not have a deny (blacklist) relevant to that resource. +It is possible to grant or deny access, or use a combination of the two. +The user will be able to access the resource if they have a `GRANT` (allowlist) and do not have a `DENY` (denylist) relevant to that resource. All other combinations of `GRANT` and `DENY` will result in the matching path being inaccessible. -What this means in practice depends on whether we are talking about a xref::access-control/privileges-reads.adoc[read privilege] or a xref::access-control/privileges-writes.adoc[write privilege]. +What this means in practice depends on whether we are talking about a <> or a <>: -* If a entity is not accessible due to xref::access-control/privileges-reads.adoc[read privileges], the data will become invisible to attempts to read it. -It will appear to the user as if they have a smaller database (smaller graph). -* If an entity is not accessible due to xref::access-control/privileges-writes.adoc[write privileges], an error will occur on any attempt to write that data. +* If an entity is not accessible due to <>, the data will become invisible. +It will appear to the user as if they had a smaller database (smaller graph). +* If an entity is not accessible due to <>, an error will occur on any attempt to write that data. [NOTE] ==== In this document we will often use the terms _'allows'_ and _'enables'_ in seemingly identical ways. However, there is a subtle difference. -We will use _'enables'_ to refer to the consequences of xref::access-control/privileges-reads.adoc[read privileges] where a restriction will not cause an error, only a reduction in the apparent graph size. -We will use _'allows'_ to refer to the consequence of xref::access-control/privileges-writes.adoc[write privileges] where a restriction can result in an error. +We will use _'enables'_ to refer to the consequences of <> where a restriction will not cause an error, only a reduction in the apparent graph size. +We will use _'allows'_ to refer to the consequence of <> where a restriction can result in an error. ==== [NOTE] ==== -If a user was not also provided with the database `ACCESS` privilege then access to the entire database will be denied. -Information about the database access privilege can be found in xref::access-control/database-administration.adoc#access-control-database-administration-access[The ACCESS privilege]. +If a user was not also provided with the database `ACCESS` privilege, then access to the entire database will be denied. +Information about the database access privilege can be found in <>. ==== [role=enterprise-edition] [[access-control-graph-privileges]] -== Graph privilege commands (`GRANT`, `DENY`, and `REVOKE`) +== Graph privilege commands (`GRANT`, `DENY` and `REVOKE`) Administrators can use Cypher commands to manage Neo4j graph administrative rights. The components of the graph privilege commands are: @@ -42,10 +40,10 @@ The components of the graph privilege commands are: * the command: ** `GRANT` – gives privileges to roles. ** `DENY` – denies privileges to roles. -** `REVOKE` – removes granted or denied privilege from roles. +** `REVOKE` – removes granted or denied privileges from roles. * _graph-privilege_ -** Can be either a xref::access-control/privileges-reads.adoc[read privilege] or xref::access-control/privileges-writes.adoc[write privilege]. +** Can be either a <> or <>. * _name_ ** The graph or graphs to associate the privilege with. @@ -54,14 +52,14 @@ When using an alias, the command will be executed on the resolved graph. + [NOTE] ==== -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 graph. +If you delete a database and create a new one with the same name, the new one will _NOT_ have the privileges previously assigned to the deleted graph. ==== -** It can be `+*+` which means all graphs. +** It can be `+*+`, which means all graphs. Graphs created after this command execution will also be associated with these privileges. ** `HOME GRAPH` refers to the graph associated with the home database for that user. -The default database will be used as home database if a user does not have a home database configured. -If the user's home database changes for any reason after privileges have been created then these privileges will be associated with the graph attached to the new database. +The default database will be used as home database if a user does not have one configured. +If the user's home database changes for any reason after privileges have been created, then these privileges will be associated with the graph attached to the new database. This can be quite powerful as it allows permissions to be switched from one graph to another simply by changing a user's home database. * _entity_ @@ -69,111 +67,38 @@ This can be quite powerful as it allows permissions to be switched from one grap *** `NODES` label (nodes with the specified label(s)). *** `RELATIONSHIPS` type (relationships of the specific type(s)). *** `ELEMENTS` label (both nodes and relationships). -** The label or type can be `+*+` which means all labels or types. +** The label or type can be referred with `+*+`, which means all labels or types. ** Multiple labels or types can be specified, comma-separated. ** Defaults to `ELEMENTS` `+*+` if omitted. -** Some of the commands for write privileges do not allow an _entity_ part, see xref::access-control/privileges-writes.adoc[Write privileges] for details. +** Some of the commands for write privileges do not allow an _entity_ part. +See <> for details. * _role[, ...]_ ** The role or roles to associate the privilege with, comma-separated. - -.General grant +ON GRAPH+ privilege syntax -[cols="<15s,<85"] -|=== - -| Command -m| +GRANT ... ON ... TO ...+ - -| Syntax -a| -[source, syntax, role="noheader", indent=0] ----- -GRANT graph-privilege ON { HOME GRAPH \| GRAPH[S] { * \| name[, ...] } } [entity] TO role[, ...] ----- - -| Description -a| Grant a privilege to one or multiple roles. - -|=== - - -.General deny +ON GRAPH+ privilege syntax -[cols="<15s,<85"] -|=== - -| Command -m| +DENY ... ON ... TO ...+ - -| Syntax -a| -[source, syntax, role="noheader", indent=0] ----- -DENY graph-privilege ON { HOME GRAPH \| GRAPH[S] { * \| name[, ...] } } [entity] TO role[, ...] ----- - -| Description -a| Deny a privilege to one or multiple roles. - +.General graph privilege command syntax +[options="header", width="100%", cols="2a,1a"] |=== +| Command | Description +| [source, cypher, role=noplay] +GRANT graph-privilege ON {HOME GRAPH \| GRAPH[S] {* \| name[, ...]}} [entity] TO role[, ...] +| Grants a privilege to one or multiple roles. -.General revoke +ON GRAPH+ privilege syntax -[cols="<15s,<85"] -|=== - -| Command -m| +REVOKE GRANT ... ON ... FROM ...+ - -| Syntax -a| -[source, syntax, role="noheader", indent=0] ----- -REVOKE GRANT graph-privilege ON { HOME GRAPH \| GRAPH[S] { * \| name[, ...] } } [entity] FROM role[, ...] ----- +| [source, cypher, role=noplay] +DENY graph-privilege ON {HOME GRAPH \| GRAPH[S] {* \| name[, ...]}} [entity] TO role[, ...] +| Denies a privilege to one or multiple roles. -| Description -a| Revoke a granted privilege from one or multiple roles. - -|=== +| [source, cypher, role=noplay] +REVOKE GRANT graph-privilege ON {HOME GRAPH \| GRAPH[S] {* \| name[, ...]}} [entity] FROM role[, ...] +| Revokes a granted privilege from one or multiple roles. +| [source, cypher, role=noplay] +REVOKE DENY graph-privilege ON {HOME GRAPH \| GRAPH[S] {* \| name[, ...]}} [entity] FROM role[, ...] +| Revokes a denied privilege from one or multiple roles. -.General revoke +ON GRAPH+ privilege syntax -[cols="<15s,<85"] -|=== - -| Command -m| +REVOKE DENY ... ON ... FROM ...+ - -| Syntax -a| -[source, syntax, role="noheader", indent=0] ----- -REVOKE DENY graph-privilege ON { HOME GRAPH \| GRAPH[S] {* \| name[, ...] } } [entity] FROM role[, ...] ----- - -| Description -a| Revoke a denied privilege from one or multiple roles. - -|=== - - -.General revoke +ON GRAPH+ privilege syntax -[cols="<15s,<85"] -|=== - -| Command -m| +REVOKE ... ON ... FROM ...+ - -| Syntax -a| -[source, syntax, role="noheader", indent=0] ----- -REVOKE graph-privilege ON { HOME GRAPH \| GRAPH[S] { * \| name[, ...] } } [entity] FROM role[, ...] ----- - -| Description -| Revoke a granted or denied privilege from one or multiple roles. - +| [source, cypher, role=noplay] +REVOKE graph-privilege ON {HOME GRAPH \| GRAPH[S] {* \| name[, ...]}} [entity] FROM role[, ...] +| Revokes a granted or denied privilege from one or multiple roles. |=== [NOTE] @@ -182,134 +107,95 @@ REVOKE graph-privilege ON { HOME GRAPH \| GRAPH[S] { * \| name[, ...] } } [entit Use `REVOKE` if you want to remove a privilege. ==== -The general grant and deny syntax is illustrated in the following image: +The general `GRANT` and `DENY` syntaxes are illustrated in the following image: -image::privileges_grant_and_deny_syntax.png[title="GRANT and DENY Syntax"] +image::grant-privileges-overview.png[title="GRANT and DENY Syntax"] -A more detailed syntax illustration would be the following image for graph privileges: +A more detailed syntax illustration for graph privileges would be the following: -image::privileges_on_graph_syntax.png[title="Syntax of GRANT and DENY Graph Privileges. The `{` and `}` are part of the syntax and not used for grouping."] +image::grant-privileges-graph.png[title="Syntax of GRANT and DENY Graph Privileges. The `{` and `}` are part of the syntax and not used for grouping."] -The following image shows the hierarchy between the different graph privileges: +The following image shows the hierarchy between different graph privileges: -image::privileges_hierarchy.png[title="Graph privileges hierarchy"] +image::privilege-hierarchy-graph.png[title="Graph privileges hierarchy"] [role=enterprise-edition] [[access-control-list-privileges]] == Listing privileges -Available privileges can be displayed using the different `SHOW PRIVILEGES` commands. +Available privileges can be displayed using the different `SHOW PRIVILEGE[S]` commands. -.Show privileges syntax -[cols="<15s,<85"] +.Show privileges command syntax +[options="header", width="100%", cols="3a,2a"] |=== - | Command -m| +SHOW PRIVILEGE+ - -| Syntax -a| -[source, syntax, role="noheader", indent=0] ----- -SHOW [ALL] PRIVILEGE[S] [AS [REVOKE] COMMAND[S]] - [YIELD { * \| field[, ...] } [ORDER BY field[, ...]] [SKIP n] [LIMIT n]] - [WHERE expression] - [RETURN field[, ...] [ORDER BY field[, ...]] [SKIP n] [LIMIT n]] ----- - | Description -| List all privileges. - -|=== - - -.Show role privileges syntax -[cols="<15s,<85"] -|=== -| Command -m| +SHOW ROLE ... PRIVILEGE+ +| [source, cypher, role=noplay] +SHOW [ALL] PRIVILEGE[S] [AS [REVOKE] COMMAND[S]] + [YIELD { * \| field[, ...] } [ORDER BY field[, ...]] [SKIP n] [LIMIT n]] + [WHERE expression] + [RETURN field[, ...] [ORDER BY field[, ...]] [SKIP n] [LIMIT n]] +| Lists all privileges. -| Syntax -a| -[source, syntax, role="noheader", indent=0] ----- +| [source, cypher, role=noplay] SHOW ROLE[S] name[, ...] PRIVILEGE[S] [AS [REVOKE] COMMAND[S]] - [YIELD { * \| field[, ...] } [ORDER BY field[, ...]] [SKIP n] [LIMIT n]] - [WHERE expression] - [RETURN field[, ...] [ORDER BY field[, ...]] [SKIP n] [LIMIT n]] ----- + [YIELD { * \| field[, ...] } [ORDER BY field[, ...]] [SKIP n] [LIMIT n]] + [WHERE expression] + [RETURN field[, ...] [ORDER BY field[, ...]] [SKIP n] [LIMIT n]] +| Lists privileges for a specific role. -| Description -| List privileges for a specific role. - -|=== - - -.Show user privileges syntax -[cols="<15s,<85"] -|=== - -| Command -m| +SHOW USER ... PRIVILEGE+ - -| Syntax -a| -[source, syntax, role="noheader", indent=0] ----- +| [source, cypher, role=noplay] SHOW USER[S] [name[, ...]] PRIVILEGE[S] [AS [REVOKE] COMMAND[S]] - [YIELD { * \| field[, ...] } [ORDER BY field[, ...]] [SKIP n] [LIMIT n]] - [WHERE expression] - [RETURN field[, ...] [ORDER BY field[, ...]] [SKIP n] [LIMIT n]] ----- - -| Description -| List privileges for a specific user, or the current user. + [YIELD { * \| field[, ...] } [ORDER BY field[, ...]] [SKIP n] [LIMIT n]] + [WHERE expression] + [RETURN field[, ...] [ORDER BY field[, ...]] [SKIP n] [LIMIT n]] +| Lists privileges for a specific user, or the current user. -| Note -| -It is only possible for a user to show their own privileges. +[NOTE] +==== +Please note that it is only possible for a user to show their own privileges. Therefore, if a non-native auth provider like LDAP is in use, `SHOW USER PRIVILEGES` will only work in a limited capacity. -Other users' privileges cannot be listed when using a non-native auth provider. +Other users' privileges cannot be listed when using a non-native auth provider. +==== |=== +When using the `RETURN` clause, the `YIELD` clause is mandatory and must not be omitted. -When using the `RETURN` clause, the `YIELD` clause is mandatory and may not be omitted. - -For an easy overview of the existing privileges, it is recommended to use the `AS COMMANDS` version of the show command. +For an easy overview of the existing privileges, it is recommended to use the `AS COMMANDS` version of the `SHOW` command. This returns the privileges as the commands that are granted or denied. -Omitting the `AS COMMANDS` clause instead gives the result as multiple columns describing the privilege: +When omitting the `AS COMMANDS` clause, results will include multiple columns describing privileges: * `access`: whether the privilege is granted or denied. -* `action`: which type of privilege this is, for example traverse, read, index management, or role management. -* `resource`: what type of scope this privilege applies to: the entire dbms, a database, a graph or sub-graph access. +* `action`: which type of privilege this is, for example traverse, read, index management or role management. +* `resource`: what type of scope this privilege applies to, i.e. the entire DBMS, a specific database, a graph or sub-graph access. * `graph`: the specific database or graph this privilege applies to. -* `segment`: when applicable, the scope this privilege applies to: labels, relationship types, procedures, functions, or transactions. -* `role`: the role the privilege is granted to. +* `segment`: when applicable, this privilege applies to labels, relationship types, procedures, functions or transactions. +* `role`: the role a privilege is granted to. [role=enterprise-edition] [[access-control-list-all-privileges]] === Examples for listing all privileges -Available privileges can be displayed using the different `SHOW PRIVILEGES` commands. +Available privileges can be displayed using the different `SHOW PRIVILEGE[S]` commands. .Command syntax -[source, cypher, role=noplay, indent=0] +[source, cypher, role=noplay] ---- SHOW [ALL] PRIVILEGE[S] [AS [REVOKE] COMMAND[S]] - [WHERE expression] + [WHERE expression] SHOW [ALL] PRIVILEGE[S] [AS [REVOKE] COMMAND[S]] - YIELD { * | field[, ...] } [ORDER BY field[, ...]] [SKIP n] [LIMIT n] - [WHERE expression] - [RETURN field[, ...] [ORDER BY field[, ...]] [SKIP n] [LIMIT n]] + YIELD { * | field[, ...] } [ORDER BY field[, ...]] [SKIP n] [LIMIT n] + [WHERE expression] + [RETURN field[, ...] [ORDER BY field[, ...]] [SKIP n] [LIMIT n]] ---- -[source, cypher, role=noplay, indent=0] +[source, cypher, role=noplay] ---- SHOW PRIVILEGES ---- @@ -604,11 +490,9 @@ Lists all privileges for all roles: It is also possible to filter and sort the results by using `YIELD`, `ORDER BY` and `WHERE`: -[source, cypher, role=noplay, indent=0] +[source, cypher, role=noplay] ---- -SHOW PRIVILEGES YIELD role, access, action, segment -ORDER BY action -WHERE role = 'admin' +SHOW PRIVILEGES YIELD role, access, action, segment ORDER BY action WHERE role = 'admin' ---- In this example: @@ -691,12 +575,11 @@ In this example: 4+a|Rows: 12 |=== -`WHERE` can be used without `YIELD`: +`WHERE` can also be used without `YIELD`: -[source, cypher, role=noplay, indent=0] +[source, cypher, role=noplay] ---- -SHOW PRIVILEGES -WHERE graph <> '*' +SHOW PRIVILEGES WHERE graph <> '*' ---- In this example, the `WHERE` clause is used to filter privileges down to those that target specific graphs only. @@ -736,11 +619,11 @@ In this example, the `WHERE` clause is used to filter privileges down to those t |=== Aggregations in the `RETURN` clause can be used to group privileges. -In this case, by user and granted / denied: +In this case, by user and `GRANTED` or `DENIED`: -[source, cypher, role=noplay, indent=0] +[source, cypher, role=noplay] ---- -SHOW PRIVILEGES YIELD * RETURN role, access, collect([graph, resource, segment, action]) AS privileges +SHOW PRIVILEGES YIELD * RETURN role, access, collect([graph, resource, segment, action]) as privileges ---- .Result @@ -788,7 +671,7 @@ SHOW PRIVILEGES YIELD * RETURN role, access, collect([graph, resource, segment, The `RETURN` clause can also be used to order and paginate the results, which is useful when combined with `YIELD` and `WHERE`. In this example the query returns privileges for display five-per-page, and skips the first five to display the second page. -[source, cypher, role=noplay, indent=0] +[source, cypher, role=noplay] ---- SHOW PRIVILEGES YIELD * RETURN * ORDER BY role SKIP 5 LIMIT 5 ---- @@ -841,9 +724,9 @@ SHOW PRIVILEGES YIELD * RETURN * ORDER BY role SKIP 5 LIMIT 5 6+a|Rows: 5 |=== -Available privileges can also be output as Cypher commands, by appending `AS COMMAND[S]` to the show command: +Available privileges can also be displayed as Cypher commands by adding `AS COMMAND[S]`: -[source, cypher, role=noplay, indent=0] +[source, cypher, role=noplay] ---- SHOW PRIVILEGES AS COMMANDS ---- @@ -892,10 +775,9 @@ a|Rows: 35 Like other `SHOW` commands, the output can also be processed using `YIELD` / `WHERE` / `RETURN`: -[source, cypher, role=noplay, indent=0] +[source, cypher, role=noplay] ---- -SHOW PRIVILEGES AS COMMANDS -WHERE command CONTAINS 'MANAGEMENT' +SHOW PRIVILEGES AS COMMANDS WHERE command CONTAINS 'MANAGEMENT' ---- .Result @@ -913,9 +795,9 @@ WHERE command CONTAINS 'MANAGEMENT' a|Rows: 8 |=== -It is also possible to get the privilege commands formatted for revoking instead of granting or denying the privileges: +It is also possible to get the privileges listed as revoking commands instead of granting or denying: -[source, cypher, role=noplay, indent=0] +[source, cypher, role=noplay] ---- SHOW PRIVILEGES AS REVOKE COMMANDS ---- @@ -962,27 +844,27 @@ SHOW PRIVILEGES AS REVOKE COMMANDS a|Rows: 35 |=== -For more info about revoking privileges, please see xref::access-control/manage-privileges.adoc#access-control-revoke-privileges[The REVOKE command]. +For more info about revoking privileges, please see <>. [role=enterprise-edition] [[access-control-list-privileges-role]] === Examples for listing privileges for specific roles -Available privileges for specific roles can be displayed using `SHOW ROLE name PRIVILEGES`. +Available privileges for specific roles can be displayed using `SHOW ROLE name PRIVILEGE[S]`: -[source, cypher, role=noplay, indent=0] +[source, cypher, role=noplay] ---- SHOW ROLE[S] name[, ...] PRIVILEGE[S] [AS [REVOKE] COMMAND[S]] - [WHERE expression] + [WHERE expression] SHOW ROLE[S] name[, ...] PRIVILEGE[S] [AS [REVOKE] COMMAND[S]] - YIELD { * | field[, ...] } [ORDER BY field[, ...]] [SKIP n] [LIMIT n] - [WHERE expression] - [RETURN field[, ...] [ORDER BY field[, ...]] [SKIP n] [LIMIT n]] + YIELD { * | field[, ...] } [ORDER BY field[, ...]] [SKIP n] [LIMIT n] + [WHERE expression] + [RETURN field[, ...] [ORDER BY field[, ...]] [SKIP n] [LIMIT n]] ---- -[source, cypher, role=noplay, indent=0] +[source, cypher, role=noplay] ---- SHOW ROLE regularUsers PRIVILEGES ---- @@ -1009,7 +891,7 @@ Lists all privileges for role `regularUsers`. 6+a|Rows: 1 |=== -[source, cypher, role=noplay, indent=0] +[source, cypher, role=noplay] ---- SHOW ROLES regularUsers, noAccessUsers PRIVILEGES ---- @@ -1043,7 +925,7 @@ Lists all privileges for roles `regularUsers` and `noAccessUsers`. 6+a|Rows: 2 |=== -Similar to the other show privilege commands, the available privileges for roles can also be output as Cypher commands with the optional `AS COMMAND[S]`. +Similar to the other `SHOW PRIVILEGES` commands, the available privileges for roles can also be listed as Cypher commands with the optional `AS COMMAND[S]`. .Result [options="header,footer", width="100%", cols="m"] @@ -1063,12 +945,11 @@ Similar to the other show privilege commands, the available privileges for roles a|Rows: 11 |=== -The output can be processed using `YIELD` / `WHERE` / `RETURN` here as well. +The output can be processed using `YIELD` / `WHERE` / `RETURN` here as well: -[source, cypher, role=noplay, indent=0] +[source, cypher, role=noplay] ---- -SHOW ROLE architect PRIVILEGES AS COMMANDS -WHERE command CONTAINS 'MATCH' +SHOW ROLE architect PRIVILEGES AS COMMANDS WHERE command CONTAINS 'MATCH' ---- .Result @@ -1080,10 +961,10 @@ WHERE command CONTAINS 'MATCH' |Rows: 2 |=== -Again, is it possible to get the privilege commands formatted for revoking instead of granting or denying the privileges. -For more info about revoking privileges, please see xref::access-control/manage-privileges.adoc#access-control-revoke-privileges[The REVOKE command]. +Again, it is possible to get the privileges listed as revoking commands instead of granting or denying. +For more info about revoking privileges, please see <>. -[source, cypher, role=noplay, indent=0] +[source, cypher, role=noplay] ---- SHOW ROLE reader PRIVILEGES AS REVOKE COMMANDS ---- @@ -1107,23 +988,22 @@ Available privileges for specific users can be displayed using `SHOW USER name P [NOTE] ==== -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. +Note that if a non-native auth provider like LDAP is in use, `SHOW USER PRIVILEGES` will only work with a limited capacity as 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. ==== -[source, cypher, role=noplay, indent=0] +[source, cypher, role=noplay] ---- SHOW USER[S] [name[, ...]] PRIVILEGE[S] [AS [REVOKE] COMMAND[S]] - [WHERE expression] + [WHERE expression] SHOW USER[S] [name[, ...]] PRIVILEGE[S] [AS [REVOKE] COMMAND[S]] - YIELD { * | field[, ...] } [ORDER BY field[, ...]] [SKIP n] [LIMIT n] - [WHERE expression] - [RETURN field[, ...] [ORDER BY field[, ...]] [SKIP n] [LIMIT n]] + YIELD { * | field[, ...] } [ORDER BY field[, ...]] [SKIP n] [LIMIT n] + [WHERE expression] + [RETURN field[, ...] [ORDER BY field[, ...]] [SKIP n] [LIMIT n]] ---- -[source, cypher, role=noplay, indent=0] +[source, cypher, role=noplay] ---- SHOW USER jake PRIVILEGES ---- @@ -1176,7 +1056,7 @@ Lists all privileges for user `jake`. 7+a|Rows: 4 |=== -[source, cypher, role=noplay, indent=0] +[source, cypher, role=noplay] ---- SHOW USERS jake, joe PRIVILEGES ---- @@ -1262,22 +1142,22 @@ Lists all privileges for users `jake` and `joe`. |=== The same command can be used at all times to review available privileges for the current user. -For this purpose, a shorter form of the the command also exists: `SHOW USER PRIVILEGES` +For this purpose, there is a shorter form of the command: `SHOW USER PRIVILEGES`: -[source, cypher, role=noplay, indent=0] +[source, cypher, role=noplay] ---- SHOW USER PRIVILEGES ---- -As for the other privilege commands, available privileges for users can also be output as Cypher commands with the optional `AS COMMAND[S]`. +As for the other privilege commands, available privileges for users can also be listed as Cypher commands with the optional `AS COMMAND[S]`. [NOTE] ==== -When showing _user_ privileges as commands, the roles in the Cypher commands are replaced with a parameter. +When showing user privileges as commands, the roles in the Cypher commands are replaced with a parameter. This can be used to quickly create new roles based on the privileges of specific users. ==== -[source, cypher, role=noplay, indent=0] +[source, cypher, role=noplay] ---- SHOW USER jake PRIVILEGES AS COMMANDS ---- @@ -1296,10 +1176,9 @@ a|Rows: 4 Like other `SHOW` commands, the output can also be processed using `YIELD` / `WHERE` / `RETURN`. Additionally, similar to the other show privilege commands, it is also possible to show the commands for revoking the privileges. -[source, cypher, role=noplay, indent=0] +[source, cypher, role=noplay] ---- -SHOW USER jake PRIVILEGES AS REVOKE COMMANDS -WHERE command CONTAINS 'EXECUTE' +SHOW USER jake PRIVILEGES AS REVOKE COMMANDS WHERE command CONTAINS 'EXECUTE' ---- .Result @@ -1312,31 +1191,31 @@ a|Rows: 2 |=== + [role=enterprise-edition] [[access-control-revoke-privileges]] == Revoking privileges Privileges that were granted or denied earlier can be revoked using the `REVOKE` command: -[source, cypher, role=noplay, indent=0] +[source, cypher, role=noplay] ---- REVOKE - [ GRANT | DENY ] graph-privilege - FROM role[, ...] + [ GRANT | DENY ] graph-privilege + FROM role[, ...] ---- An example usage of the `REVOKE` command is given here: -[source, cypher, role=noplay, indent=0] +[source, cypher, role=noplay] ---- REVOKE GRANT TRAVERSE ON HOME GRAPH NODES Post FROM regularUsers ---- -While it can be explicitly specified that revoke should remove a `GRANT` or `DENY`, it is also possible to revoke either one by not specifying at all as the next example demonstrates. -Because of this, if there happen to be a `GRANT` and a `DENY` on the same privilege, it would remove both. +While it can be explicitly specified that `REVOKE` should remove a `GRANT` or `DENY`, it is also possible to `REVOKE` both by not specifying them at all, as the next example demonstrates. +Because of this, if there happens to be a `GRANT` and a `DENY` for the same privilege, it would remove both. -[source, cypher, role=noplay, indent=0] +[source, cypher, role=noplay] ---- REVOKE TRAVERSE ON HOME GRAPH NODES Payments FROM regularUsers ---- - diff --git a/modules/ROOT/pages/access-control/manage-roles.adoc b/modules/ROOT/pages/access-control/manage-roles.adoc index eb3575950..352c7fc1d 100644 --- a/modules/ROOT/pages/access-control/manage-roles.adoc +++ b/modules/ROOT/pages/access-control/manage-roles.adoc @@ -1,5 +1,3 @@ -:description: This section explains how to use Cypher to manage roles in Neo4j. - [role=enterprise-edition] [[access-control-manage-roles]] = Managing roles @@ -11,7 +9,7 @@ This section explains how to use Cypher to manage roles in Neo4j. Roles can be created and managed using a set of Cypher administration commands executed against the `system` database. -When connected to the DBMS over bolt, administration commands are automatically routed to the `system` database. +When connected to the DBMS over `bolt`, administration commands are automatically routed to the `system` database. [[access-control-role-syntax]] @@ -19,13 +17,12 @@ When connected to the DBMS over bolt, administration commands are automatically [cols="<15s,<85"] |=== - | Command m| SHOW ROLES | Syntax a| -[source, syntax, role="noheader", indent=0] +[source, cypher, role=noplay] ---- SHOW [ALL\|POPULATED] ROLES [YIELD { * \| field[, ...] } [ORDER BY field[, ...]] [SKIP n] [LIMIT n]] @@ -34,34 +31,26 @@ SHOW [ALL\|POPULATED] ROLES ---- | Description -a| -List roles. +a| Lists roles. -When using the `RETURN` clause, the `YIELD` clause is mandatory and may not be omitted. +When using the `RETURN` clause, the `YIELD` clause is mandatory and must not be omitted. -For more information, see xref::access-control/manage-roles.adoc#access-control-list-roles[Listing roles]. +For more information, see <>. | Required privilege -a| -[source, privilege, role="noheader", indent=0] ----- -GRANT SHOW ROLE ----- - -(see xref::access-control/dbms-administration.adoc#access-control-dbms-administration-role-management[DBMS ROLE MANAGEMENT privileges]) +a| `GRANT SHOW ROLE` +(see <>) |=== - [cols="<15s,<85"] |=== - | Command m| SHOW ROLES WITH USERS | Syntax a| -[source, syntax, role="noheader", indent=0] +[source, cypher, role=noplay] ---- SHOW [ALL\|POPULATED] ROLES WITH USERS [YIELD { * \| field[, ...] } [ORDER BY field[, ...]] [SKIP n] [LIMIT n]] @@ -70,41 +59,30 @@ SHOW [ALL\|POPULATED] ROLES WITH USERS ---- | Description -a| -List roles and users assigned to them. +a| Lists roles and users assigned to them. -When using the `RETURN` clause, the `YIELD` clause is mandatory and may not be omitted. +When using the `RETURN` clause, the `YIELD` clause is mandatory and must not be omitted. -For more information, see xref::access-control/manage-roles.adoc#access-control-list-roles[Listing roles]. +For more information, see <>. | Required privilege -a| -[source, privilege, role="noheader", indent=0] ----- -GRANT SHOW ROLE ----- +a| `GRANT SHOW ROLE` -[source, privilege, role="noheader", indent=0] ----- -GRANT SHOW USER ----- +(see <>) -(see xref::access-control/dbms-administration.adoc#access-control-dbms-administration-role-management[DBMS ROLE MANAGEMENT privileges]) - -(see xref::access-control/dbms-administration.adoc#access-control-dbms-administration-user-management[DBMS USER MANAGEMENT privileges]) +`GRANT SHOW USER` +(see <>) |=== - [cols="<15s,<85"] |=== - | Command m| SHOW ROLE PRIVILEGES | Syntax a| -[source, syntax, role="noheader", indent=0] +[source, cypher, role=noplay] ---- SHOW ROLE[S] name[, ...] PRIVILEGE[S] [AS [REVOKE] COMMAND[S]] [YIELD { * \| field[, ...] } [ORDER BY field[, ...]] [SKIP n] [LIMIT n]] @@ -113,53 +91,39 @@ SHOW ROLE[S] name[, ...] PRIVILEGE[S] [AS [REVOKE] COMMAND[S]] ---- | Description -a| -List the privileges granted to the specified roles. +a| Lists the privileges granted to the specified roles. -When using the `RETURN` clause, the `YIELD` clause is mandatory and may not be omitted. +When using the `RETURN` clause, the `YIELD` clause is mandatory and must not be omitted. -For more information, see xref::access-control/manage-privileges.adoc#access-control-list-privileges[Listing privileges]. +For more information, see <>. | Required privilege -a| -[source, privilege, role="noheader", indent=0] ----- -GRANT SHOW PRIVILEGE ----- - -(see xref::access-control/dbms-administration.adoc#access-control-dbms-administration-privilege-management[DBMS PRIVILEGE MANAGEMENT privileges]) +a| GRANT SHOW PRIVILEGE +(see <>) |=== - [cols="<15s,<85"] |=== - | Command m| CREATE ROLE | Syntax a| -[source, syntax, role="noheader", indent=0] +[source, cypher, role=noplay] ---- CREATE ROLE name [IF NOT EXISTS] [AS COPY OF otherName] ---- | Description -a| -Create a new role. +a| Creates a new role. -For more information, see xref::access-control/manage-roles.adoc#access-control-create-roles[Creating roles]. +For more information, see <>. | Required privilege -a| -[source, privilege, role="noheader", indent=0] ----- -GRANT CREATE ROLE ----- - -(see xref::access-control/dbms-administration.adoc#access-control-dbms-administration-role-management[DBMS ROLE MANAGEMENT privileges]) +a| `GRANT CREATE ROLE` +(see <>) |=== [cols="<15s,<85"] @@ -169,95 +133,68 @@ m| CREATE OR REPLACE ROLE | Syntax a| -[source, syntax, role="noheader", indent=0] +[source, cypher, role=noplay] ---- CREATE OR REPLACE ROLE name [AS COPY OF otherName] ---- | Description -a| -Create a new role, or if a role with the same name exists, replace it. +a| Creates a new role, or if a role with the same name exists, replace it. -For more information, see xref::access-control/manage-roles.adoc#access-control-create-roles[Creating roles]. +For more information, see <>. | Required privilege -a| -[source, privilege, role="noheader", indent=0] ----- -GRANT CREATE ROLE ----- - -[source, privilege, role="noheader", indent=0] ----- -GRANT DROP ROLE ----- - -(see xref::access-control/dbms-administration.adoc#access-control-dbms-administration-role-management[DBMS ROLE MANAGEMENT privileges]) +a| `GRANT CREATE ROLE` and `GRANT DROP ROLE` +(see <>) |=== - [cols="<15s,<85"] |=== - | Command m| RENAME ROLE | Syntax a| -[source, syntax, role="noheader", indent=0] +[source, cypher, role=noplay] ---- RENAME ROLE name [IF EXISTS] TO otherName ---- | Description -a| -Change the name of a role. +a| Changes the name of a role. -For more information, see xref::access-control/manage-roles.adoc#access-control-rename-roles[Renaming roles]. +For more information, see <>. | Required privilege -a| -[source, privilege, role="noheader", indent=0] ----- -GRANT RENAME ROLE ----- - -(see xref::access-control/dbms-administration.adoc#access-control-dbms-administration-role-management[DBMS ROLE MANAGEMENT privileges]) +a| `GRANT RENAME ROLE` +(see <>) |=== - [cols="<15s,<85"] |=== - | Command m| DROP ROLE | Syntax a| -[source, syntax, role="noheader", indent=0] +[source, cypher, role=noplay] ---- DROP ROLE name [IF EXISTS] ---- | Description -a| Remove a role. +a| Removes a role. -For more information, see xref::access-control/manage-roles.adoc#access-control-drop-roles[Deleting roles]. +For more information, see <>. | Required privilege -a| -[source, privilege, role="noheader", indent=0] ----- -GRANT DROP ROLE ----- - -(see xref::access-control/dbms-administration.adoc#access-control-dbms-administration-role-management[DBMS ROLE MANAGEMENT privileges]) +a| `GRANT DROP ROLE` +(see <>) |=== - [cols="<15s,<85"] |=== | Command @@ -265,57 +202,43 @@ m| GRANT ROLE TO | Syntax a| -[source, syntax, role="noheader", indent=0] +[source, cypher, role=noplay] ---- GRANT ROLE[S] name[, ...] TO user[, ...] ---- | Description -a| -Assign roles to users. +a| Assigns roles to users. -For more information, see xref::access-control/manage-roles.adoc#access-control-assign-roles[Assigning roles to users]. +For more information, see <>. | Required privilege -a| -[source, privilege, role="noheader", indent=0] ----- -GRANT ASSIGN ROLE ----- - -(see xref::access-control/dbms-administration.adoc#access-control-dbms-administration-role-management[DBMS ROLE MANAGEMENT privileges]) +a| `GRANT ASSIGN ROLE` +(see <>) |=== - [cols="<15s,<85"] |=== - | Command m| REVOKE ROLE | Syntax a| -[source, syntax, role="noheader", indent=0] +[source, cypher, role=noplay] ---- REVOKE ROLE[S] name[, ...] FROM user[, ...] ---- | Description -a| -Remove roles from users. +a| Removes roles from users. -For more information, see xref::access-control/manage-roles.adoc#access-control-revoke-roles[Revoking roles from users]. +For more information, see <>. | Required privilege -a| -[source, privilege, role="noheader", indent=0] ----- -GRANT REMOVE ROLE ----- - -(see xref::access-control/dbms-administration.adoc#access-control-dbms-administration-role-management[DBMS ROLE MANAGEMENT privileges]) +a| `GRANT REMOVE ROLE` +(see <>) |=== @@ -324,18 +247,19 @@ GRANT REMOVE ROLE Available roles can be seen using `SHOW ROLES`: -[source, cypher, role=noplay, indent=0] +[source, cypher, role=noplay] ---- SHOW ROLES ---- This is the same command as `SHOW ALL ROLES`. -When first starting a Neo4j DBMS there are a number of built-in roles: +When first starting a Neo4j DBMS, there are a number of built-in roles: -* `PUBLIC` - a role that all users have granted, by default it gives access to the home database and execute privileges for procedures and functions. -* `reader` - can perform traverse and read operations on all databases except `system`. -* `editor` - can perform traverse, read, and write operations on all databases except `system`, but cannot make new labels or relationship types. +* `PUBLIC` - a role that all users have granted. +By default it gives access to the home database and to execute privileges for procedures and functions. +* `reader` - can perform traverse and read operations in all databases except `system`. +* `editor` - can perform traverse, read, and write operations in all databases except `system`, but cannot create new labels or relationship types. * `publisher` - can do the same as `editor`, but also create new labels and relationship types. * `architect` - can do the same as `publisher` as well as create and manage indexes and constraints. * `admin` - can do the same as all the above, as well as manage databases, aliases, users, roles, and privileges. @@ -355,14 +279,14 @@ When first starting a Neo4j DBMS there are a number of built-in roles: 1+a|Rows: 6 |=== -More information about the built-in roles can be found in xref:4.4@operations-manual:ROOT:authentication-authorization/built-in-roles/index.adoc[Operations Manual -> Built-in roles] +More information about the built-in roles can be found in < Built-in roles>>. There are multiple versions of this command, the default being `SHOW ALL ROLES`. To only show roles that are assigned to users, the command is `SHOW POPULATED ROLES`. -To see which users are assigned to roles `WITH USERS` can be appended to the commands. -This will give one result row for each user, so if a role is assigned to two users then it will show up twice in the result. +To see which users are assigned to roles, `WITH USERS` can be added to the command. +This will give a result with one row for each user, so if a role is assigned to two users, then it will show up twice. -[source, cypher, role=noplay, indent=0] +[source, cypher, role=noplay] ---- SHOW POPULATED ROLES WITH USERS ---- @@ -396,19 +320,17 @@ The table of results will show information about the role and what database it b 2+a|Rows: 6 |=== -It is also possible to filter and sort the results by using `YIELD`, `ORDER BY`, and `WHERE`: +It is also possible to filter and sort the results by using `YIELD`, `ORDER BY` and `WHERE`: -[source, cypher, role=noplay, indent=0] +[source, cypher, role=noplay] ---- -SHOW ROLES YIELD role -ORDER BY role -WHERE role ENDS WITH 'r' +SHOW ROLES YIELD role ORDER BY role WHERE role ENDS WITH 'r' ---- In this example: * The results have been filtered to only return the roles ending in 'r'. -* The results are ordered by the 'action' column using `ORDER BY`. +* The results are ordered by the `action` column using `ORDER BY`. It is also possible to use `SKIP` and `LIMIT` to paginate the results. @@ -426,23 +348,23 @@ It is also possible to use `SKIP` and `LIMIT` to paginate the results. [NOTE] ==== -The `SHOW ROLE name PRIVILEGES` command is found in xref::access-control/manage-privileges.adoc#access-control-list-privileges[Listing privileges]. +The `SHOW ROLE name PRIVILEGES` command is found in <>. ==== [[access-control-create-roles]] == Creating roles -Roles can be created using `CREATE ROLE`. +Roles can be created using `CREATE ROLE`: -[source, cypher, role=noplay, indent=0] +[source, cypher, role=noplay] ---- CREATE ROLE name [IF NOT EXISTS] [AS COPY OF otherName] ---- -Roles can be created or replaced by using `CREATE OR REPLACE ROLE`. +Roles can be created or replaced by using `CREATE OR REPLACE ROLE`: -[source, cypher, role=noplay, indent=0] +[source, cypher, role=noplay] ---- CREATE OR REPLACE ROLE name [AS COPY OF otherName] ---- @@ -460,7 +382,7 @@ A role can be copied, keeping its privileges, using `CREATE ROLE name AS COPY OF .Copy a role ====== -[source, cypher, role=noplay, indent=0] +[source, cypher, role=noplay] ---- CREATE ROLE mysecondrole AS COPY OF myrole ---- @@ -470,7 +392,7 @@ Created roles will appear on the list provided by `SHOW ROLES`. .List roles ====== -[source, cypher, role=noplay, indent=0] +[source, cypher, role=noplay] ---- SHOW ROLES ---- @@ -494,36 +416,28 @@ SHOW ROLES ====== The `CREATE ROLE` command is optionally idempotent, with the default behavior to throw an exception if the role already exists. -Appending `IF NOT EXISTS` to the `CREATE ROLE` command will ensure that no exception is thrown and nothing happens should the role already exist. - +Adding `IF NOT EXISTS` to the `CREATE ROLE` command will ensure that no exception is thrown and nothing happens should the role already exist. .Create role if not exists ====== - -[source, cypher, role=noplay, indent=0] +[source, cypher, role=noplay] ---- CREATE ROLE myrole IF NOT EXISTS ---- - ====== - The `CREATE OR REPLACE ROLE` command will result in any existing role being deleted and a new one created. - .Create or replace role ====== - -[source, cypher, role=noplay, indent=0] +[source, cypher, role=noplay] ---- CREATE OR REPLACE ROLE myrole ---- This is equivalent to running `DROP ROLE myrole IF EXISTS` followed by `CREATE ROLE myrole`. - ====== - [NOTE] ==== * The `CREATE OR REPLACE ROLE` command does not allow you to use the `IF NOT EXISTS`. @@ -535,12 +449,12 @@ This is equivalent to running `DROP ROLE myrole IF EXISTS` followed by `CREATE R Roles can be renamed using `RENAME ROLE` command: -[source, cypher, role=noplay, indent=0] +[source, cypher, role=noplay] ---- RENAME ROLE mysecondrole TO mythirdrole ---- -[source, cypher, role=noplay, indent=0] +[source, cypher, role=noplay] ---- SHOW ROLES ---- @@ -573,14 +487,14 @@ The `RENAME ROLE` command is only available when using native authentication and Users can be given access rights by assigning them roles using `GRANT ROLE`: -[source, cypher, role=noplay, indent=0] +[source, cypher, role=noplay] ---- GRANT ROLE myrole TO bob ---- -The roles assigned to each user can be seen in the list provided by `SHOW USERS`: +The roles assigned to each user can be seen on the list provided by `SHOW USERS`: -[source, cypher, role=noplay, indent=0] +[source, cypher, role=noplay] ---- SHOW ROLES ---- @@ -629,12 +543,12 @@ SHOW ROLES It is possible to assign multiple roles to multiple users in one command: -[source, cypher, role=noplay, indent=0] +[source, cypher, role=noplay] ---- GRANT ROLES role1, role2 TO user1, user2, user3 ---- -[source, cypher, role=noplay, indent=0] +[source, cypher, role=noplay] ---- SHOW ROLES ---- @@ -687,14 +601,14 @@ SHOW ROLES Users can lose access rights by revoking their role using `REVOKE ROLE`: -[source, cypher, role=noplay, indent=0] +[source, cypher, role=noplay] ---- REVOKE ROLE myrole FROM bob ---- -The roles revoked from users can no longer be seen in the list provided by `SHOW USERS`: +The roles revoked from users can no longer be seen on the list provided by `SHOW USERS`: -[source, cypher, role=noplay, indent=0] +[source, cypher, role=noplay] ---- SHOW ROLES ---- @@ -743,7 +657,7 @@ SHOW ROLES It is possible to revoke multiple roles from multiple users in one command: -[source, cypher, role=noplay, indent=0] +[source, cypher, role=noplay] ---- REVOKE ROLES role1, role2 FROM user1, user2, user3 ---- @@ -754,14 +668,14 @@ REVOKE ROLES role1, role2 FROM user1, user2, user3 Roles can be deleted using `DROP ROLE` command: -[source, cypher, role=noplay, indent=0] +[source, cypher, role=noplay] ---- DROP ROLE mythirdrole ---- When a role has been deleted, it will no longer appear on the list provided by `SHOW ROLES`: -[source, cypher, role=noplay, indent=0] +[source, cypher, role=noplay] ---- SHOW ROLES ---- @@ -782,11 +696,10 @@ SHOW ROLES 1+a|Rows: 8 |=== -This command is optionally idempotent, with the default behavior to throw an exception if the role does not exists. -Appending `IF EXISTS` to the command will ensure that no exception is thrown and nothing happens should the role not exist: +This command is optionally idempotent, with the default behavior to throw an exception if the role does not exist. +Adding `IF EXISTS` to the command will ensure that no exception is thrown and nothing happens should the role not exist: -[source, cypher, role=noplay, indent=0] +[source, cypher, role=noplay] ---- DROP ROLE mythirdrole IF EXISTS ---- - diff --git a/modules/ROOT/pages/access-control/manage-users.adoc b/modules/ROOT/pages/access-control/manage-users.adoc index cc314eee6..0c64bf725 100644 --- a/modules/ROOT/pages/access-control/manage-users.adoc +++ b/modules/ROOT/pages/access-control/manage-users.adoc @@ -1,5 +1,3 @@ -:description: This section explains how to use Cypher to manage users in Neo4j. - [[access-control-manage-users]] = Managing users @@ -17,13 +15,12 @@ When connected to the DBMS over `bolt`, administration commands are automaticall [cols="<15s,<85"] |=== - | Command m| SHOW CURRENT USER | Syntax a| -[source, syntax, role="noheader", indent=0] +[source, cypher, role=noplay] ---- SHOW CURRENT USER [YIELD { * \| field[, ...] } [ORDER BY field[, ...]] [SKIP n] [LIMIT n]] @@ -32,28 +29,24 @@ SHOW CURRENT USER ---- | Description -a| -Lists the current user. +a| Lists the current user. -When using the `RETURN` clause, the `YIELD` clause is mandatory and may not be omitted. +When using the `RETURN` clause, the `YIELD` clause is mandatory and must not be omitted. -For more information, see xref::access-control/manage-users.adoc#access-control-current-users[Listing current user]. +For more information, see <>. | Required privilege a| None - |=== - [cols="<15s,<85"] |=== - | Command m| SHOW USERS | Syntax a| -[source, syntax, role="noheader", indent=0] +[source, cypher, role=noplay] ---- SHOW USERS [YIELD { * \| field[, ...] } [ORDER BY field[, ...]] [SKIP n] [LIMIT n]] @@ -62,25 +55,18 @@ SHOW USERS ---- | Description -a| -List all users. +a| Lists all users. -When using the `RETURN` clause, the `YIELD` clause is mandatory and may not be omitted. +When using the `RETURN` clause, the `YIELD` clause is mandatory and must not be omitted. -For more information, see xref::access-control/manage-users.adoc#access-control-list-users[Listing users]. +For more information, see <>. | Required privilege -a| -[source, privilege, role="noheader", indent=0] ----- -GRANT SHOW USER ----- - -(see xref::access-control/dbms-administration.adoc#access-control-dbms-administration-user-management[DBMS USER MANAGEMENT privileges]) +a| `GRANT SHOW USER` +(see <>) |=== - [cols="<15s,<85"] |=== | Command @@ -88,7 +74,7 @@ m| SHOW USER PRIVILEGES | Syntax a| -[source, syntax, role="noheader", indent=0] +[source, cypher, role=noplay] ---- SHOW USER[S] [name[, ...]] PRIVILEGE[S] [AS [REVOKE] COMMAND[S]] [YIELD { * \| field[, ...] } [ORDER BY field[, ...]] [SKIP n] [LIMIT n]] @@ -97,29 +83,20 @@ SHOW USER[S] [name[, ...]] PRIVILEGE[S] [AS [REVOKE] COMMAND[S]] ---- | Description -a| -List the privileges granted to the specified users or the current user if no user is specified. +a| Lists the privileges granted to the specified users or the current user if no user is specified. -When using the `RETURN` clause, the `YIELD` clause is mandatory and may not be omitted. +When using the `RETURN` clause, the `YIELD` clause is mandatory and must not be omitted. -For more information, see xref::access-control/manage-privileges.adoc#access-control-list-privileges[Listing privileges]. +For more information, see <>. | Required privilege -a| -[source, privilege, role="noheader", indent=0] ----- -GRANT SHOW PRIVILEGE ----- +a| `GRANT SHOW PRIVILEGE` -[source, privilege, role="noheader", indent=0] ----- -GRANT SHOW USER ----- +(see <>) -(see xref::access-control/dbms-administration.adoc#access-control-dbms-administration-privilege-management[DBMS PRIVILEGE MANAGEMENT privileges]) - -(see xref::access-control/dbms-administration.adoc#access-control-dbms-administration-user-management[DBMS USER MANAGEMENT privileges]) +`GRANT SHOW USER` +(see <>) |=== [cols="<15s,<85"] @@ -129,7 +106,7 @@ m| CREATE USER | Syntax a| -[source, syntax, role="noheader", indent=0] +[source, cypher, role=noplay] ---- CREATE USER name [IF NOT EXISTS] SET [PLAINTEXT \| ENCRYPTED] PASSWORD 'password' @@ -139,20 +116,14 @@ CREATE USER name [IF NOT EXISTS] ---- | Description -a| -Create a new user. +a| Creates a new user. -For more information, see xref::access-control/manage-users.adoc#access-control-create-users[Creating users]. +For more information, see <>. | Required privilege -a| -[source, privilege, role="noheader", indent=0] ----- -GRANT CREATE USER ----- - -(see xref::access-control/dbms-administration.adoc#access-control-dbms-administration-user-management[DBMS USER MANAGEMENT privileges]) +a| `GRANT CREATE USER` +(see <>) |=== [cols="<15s,<85"] @@ -162,7 +133,7 @@ m| CREATE OR REPLACE USER | Syntax a| -[source, syntax, role="noheader", indent=0] +[source, cypher, role=noplay] ---- CREATE OR REPLACE USER name SET [PLAINTEXT \| ENCRYPTED] PASSWORD 'password' @@ -172,25 +143,14 @@ CREATE OR REPLACE USER name ---- | Description -a| -Create a new user, or if a user with the same name exists, replace it. +a| Creates a new user, or if a user with the same name exists, replace it. -For more information, see xref::access-control/manage-users.adoc#access-control-create-users[Creating users]. +For more information, see <>. | Required privilege -a| -[source, privilege, role="noheader", indent=0] ----- -GRANT CREATE USER ----- - -[source, privilege, role="noheader", indent=0] ----- -GRANT DROP USER ----- - -(see xref::access-control/dbms-administration.adoc#access-control-dbms-administration-user-management[DBMS USER MANAGEMENT privileges]) +a| `GRANT CREATE USER` and `GRANT DROP USER` +(see <>) |=== [cols="<15s,<85"] @@ -200,26 +160,20 @@ m| RENAME USER | Syntax a| -[source, syntax, role="noheader", indent=0] +[source, cypher, role=noplay] ---- RENAME USER name [IF EXISTS] TO otherName ---- | Description -a| -Change the name of a user. +a| Changes the name of a user. -For more information, see xref::access-control/manage-users.adoc#access-control-rename-users[Renaming users]. +For more information, see <>. | Required privilege -a| -[source, privilege, role="noheader", indent=0] ----- -GRANT RENAME USER ----- - -(see xref::access-control/dbms-administration.adoc#access-control-dbms-administration-user-management[DBMS USER MANAGEMENT privileges]) +a| `GRANT RENAME USER` +(see <>) |=== [cols="<15s,<85"] @@ -229,7 +183,7 @@ m| ALTER USER | Syntax a| -[source, syntax, role="noheader", indent=0] +[source, cypher, role=noplay] ---- ALTER USER name [IF EXISTS] [SET [PLAINTEXT \| ENCRYPTED] PASSWORD 'password'] @@ -240,86 +194,60 @@ ALTER USER name [IF EXISTS] ---- | Description -a| -Modify the settings for an existing user. At least one `SET` or `REMOVE` clause is required. `SET` and `REMOVE` clauses cannot be combined in the same command. +a| Modifies the settings for an existing user. +At least one `SET` or `REMOVE` clause is required. +`SET` and `REMOVE` clauses cannot be combined in the same command. -For more information, see xref::access-control/manage-users.adoc#access-control-alter-users[Modifying users]. +For more information, see <>. | Required privilege -a| -[source, privilege, role="noheader", indent=0] ----- -GRANT SET PASSWORD ----- - -[source, privilege, role="noheader", indent=0] ----- -GRANT SET USER STATUS ----- - -[source, privilege, role="noheader", indent=0] ----- -GRANT SET USER HOME DATABASE ----- - -(see xref::access-control/dbms-administration.adoc#access-control-dbms-administration-user-management[DBMS USER MANAGEMENT privileges]) +a| `GRANT SET PASSWORD`, `GRANT SET USER STATUS`, and/or `GRANT SET USER HOME DATABASE` +(see <>) |=== - [cols="<15s,<85"] |=== - | Command m| ALTER CURRENT USER SET PASSWORD | Syntax a| -[source, syntax, role="noheader", indent=0] +[source, cypher, role=noplay] ---- ALTER CURRENT USER SET PASSWORD FROM 'oldPassword' TO 'newPassword' ---- | Description -a| -Change the current user's password. +a| Change the current user's password. -For more information, see xref::access-control/manage-users.adoc#access-control-alter-password[Changing the current user's password]. +For more information, see <>. | Required privilege a| None - |=== - [cols="<15s,<85"] |=== - | Command m| DROP USER | Syntax a| -[source, syntax, role="noheader", indent=0] +[source, cypher, role=noplay] ---- DROP USER name [IF EXISTS] ---- | Description -a| -Remove an existing user. +a| Removes an existing user. -For more information, see xref::access-control/manage-users.adoc#access-control-drop-users[Delete users]. +For more information, see <>. | Required privilege -a| -[source, privilege, role="noheader", indent=0] ----- -GRANT DROP USER ----- - -(see xref::access-control/dbms-administration.adoc#access-control-dbms-administration-user-management[DBMS USER MANAGEMENT privileges]) +a| `GRANT DROP USER` +(see <>) |=== @@ -332,7 +260,7 @@ The `SHOW USER[S] PRIVILEGES` command is only available in Neo4j Enterprise Edit [[access-control-current-users]] == Listing current user -The currently logged-in user can be seen using `SHOW CURRENT USER` which will produce a table with the following columns: +The currently logged-in user can be seen using `SHOW CURRENT USER`, which will produce a table with the following columns: [options="header", width="100%", cols="2a,4,^.^,^.^"] |=== @@ -362,13 +290,13 @@ The currently logged-in user can be seen using `SHOW CURRENT USER` which will pr | {check-mark} | home -| The home database configured for the user, or `null` if no home database has been configured. -If this database is unavailable, and the user does not specify a database to use they will not be able to log in. +| The home database configured by the user, or `null` if no home database has been configured. +If this database is unavailable and the user does not specify a database to use, they will not be able to log in. | {cross-mark} | {check-mark} |=== -[source, cypher, role=noplay, indent=0] +[source, cypher, role=noplay] ---- SHOW CURRENT USER ---- @@ -400,7 +328,7 @@ This command is only supported for a logged-in user and will return an empty res [[access-control-list-users]] == Listing users -Available users can be seen using `SHOW USERS` which will produce a table of users with the following columns: +Available users can be seen using `SHOW USERS`, which will produce a table of users with the following columns: [options="header", width="100%", cols="2a,4,^.^,^.^"] |=== @@ -430,14 +358,14 @@ Available users can be seen using `SHOW USERS` which will produce a table of use | {check-mark} | home -| The home database configured for the user, or `null` if no home database has been configured. +| The home database configured by the user, or `null` if no home database has been configured. A home database will be resolved if it is either pointing to a database or a database alias. -If this database is unavailable, and the user does not specify a database to use they will not be able to log in. +If this database is unavailable and the user does not specify a database to use, they will not be able to log in. | {cross-mark} | {check-mark} |=== -[source, cypher, role=noplay, indent=0] +[source, cypher, role=noplay] ---- SHOW USERS ---- @@ -461,16 +389,16 @@ SHOW USERS |=== When first starting a Neo4j DBMS, there is always a single default user `neo4j` with administrative privileges. -It is possible to set the initial password using xref:4.4@operations-manual:ROOT:configuration/set-initial-password/index.adoc[neo4j-admin set-initial-password], otherwise it is necessary to change the password after the first login. +It is possible to set the initial password using <>, otherwise it is necessary to change the password after the first login. .Show user ====== -This example show how: +This example shows how to: * Reorder the columns using a `YIELD` clause. * Filter the results using a `WHERE` clause. -[source, cypher, role=noplay, indent=0] +[source,cypher,role=noplay] ---- SHOW USERS YIELD user, suspended, passwordChangeRequired, roles, home WHERE user = 'jake' @@ -482,7 +410,7 @@ WHERE user = 'jake' It is possible to add a `RETURN` clause to further manipulate the results after filtering. In this example, the `RETURN` clause is used to filter out the `roles` column and rename the `user` column to `adminUser`. -[source,cypher,role=noplay, indent=0] +[source,cypher,role=noplay] ---- SHOW USERS YIELD roles, user WHERE 'admin' IN roles @@ -492,7 +420,7 @@ RETURN user AS adminUser [NOTE] ==== -The `SHOW USER name PRIVILEGES` command is described in xref::access-control/manage-privileges.adoc#access-control-list-privileges[Listing privileges]. +The `SHOW USER name PRIVILEGES` command is described in <>. ==== @@ -501,7 +429,7 @@ The `SHOW USER name PRIVILEGES` command is described in xref::access-control/man Users can be created using `CREATE USER`. -[source, syntax, role="noheader", indent=0] +[source, cypher, role=noplay] ---- CREATE USER name [IF NOT EXISTS] SET [PLAINTEXT | ENCRYPTED] PASSWORD 'password' @@ -512,7 +440,7 @@ CREATE USER name [IF NOT EXISTS] Users can be created or replaced using `CREATE OR REPLACE USER`. -[source, syntax, role="noheader", indent=0] +[source, cypher, role=noplay] ---- CREATE OR REPLACE USER name SET [PLAINTEXT | ENCRYPTED] PASSWORD 'password' @@ -524,13 +452,13 @@ CREATE OR REPLACE USER name * For `SET PASSWORD`: ** The `password` can either be a string value or a string parameter. ** All passwords are encrypted (hashed) when stored in the Neo4j `system` database. -`PLAINTEXT` and `ENCRYPTED` just refer to the format of the password in the Cypher command, i.e., whether Neo4j needs to hash it or it has already been hashed. -Therefore, it is never possible to get the plaintext of a password back out of the database. +`PLAINTEXT` and `ENCRYPTED` just refer to the format of the password in the Cypher command, i.e. whether Neo4j needs to hash it or it has already been hashed. +Consequently, it is never possible to get the plaintext of a password back out of the database. A password can be set in either fashion at any time. ** The optional `PLAINTEXT` in `SET PLAINTEXT PASSWORD` has the same behavior as `SET PASSWORD`. ** The optional `ENCRYPTED` is used to recreate an existing user when the plaintext password is unknown, but the encrypted password is available in the _data/scripts/databasename/restore_metadata.cypher_ file of a database backup. -See xref:4.4@operations-manual:ROOT:backup-restore/restore-backup/index.adoc#restore-backup-example[Operations Manual -> Restore a database backup -> Example]. + -With `ENCRYPTED`, the password string is expected to be in the format of `,,`, where, for example: +See < Restore a database backup -> Example>>. + +With `ENCRYPTED`, the password string is expected to be in the format of ``,`` or ``, where, for example: *** `0` is the first version and refers to the `SHA-256` cryptographic hash function with iterations `1`. *** `1` is the second version and refers to the `SHA-256` cryptographic hash function with iterations `1024`. * If the optional `SET PASSWORD CHANGE [NOT] REQUIRED` is omitted, the default is `CHANGE REQUIRED`. @@ -547,38 +475,32 @@ User names are case sensitive. The created user will appear on the list provided by `SHOW USERS`. * In Neo4j Community Edition there are no roles, but all users have implied administrator privileges. -* In Neo4j Enterprise Edition all users are automatically assigned the xref::access-control/built-in-roles.adoc#access-control-built-in-roles-public[`PUBLIC` role], giving them a base set of privileges. +* In Neo4j Enterprise Edition all users are automatically assigned the <>, giving them a base set of privileges. ==== - .Create user ====== +For example, you can create the user `jake` in a suspended state, with the home database `anotherDb`, and the requirement to change the password by using the command: -For example, you can create the user `jake` in a suspended state, with the home database `anotherDb`, and the requirement to change the password, using the command: - -[source, cypher, role=noplay, indent=0] +[source,cypher,role=noplay] ---- CREATE USER jake SET PASSWORD 'abc' CHANGE REQUIRED SET STATUS SUSPENDED SET HOME DATABASE anotherDb ---- - ====== - .Create user ====== +Or you can recreate the user `jake` in an active state, with an encrypted password (taken from the _data/scripts/databasename/restore_metadata.cypher_ of a database backup), and the requirement to not change the password by running: -Or, you can recreate the user `jake` in an active state, with an encrypted password (taken from the _data/scripts/databasename/restore_metadata.cypher_ of a database backup), and the requirement not to change the password, by running: - -[source, cypher, role=noplay, indent=0] +[source,cypher,role=noplay] ---- CREATE USER jake SET ENCRYPTED PASSWORD '1,6d57a5e0b3317055454e455f96c98c750c77fb371f3f0634a1b8ff2a55c5b825,190ae47c661e0668a0c8be8a21ff78a4a34cdf918cae3c407e907b73932bd16c' CHANGE NOT REQUIRED SET STATUS ACTIVE ---- - ====== [NOTE] @@ -589,51 +511,45 @@ The `SET STATUS {ACTIVE | SUSPENDED}` and `SET HOME DATABASE` parts of the comma The `CREATE USER` command is optionally idempotent, with the default behavior to throw an exception if the user already exists. Appending `IF NOT EXISTS` to the `CREATE USER` command will ensure that no exception is thrown and nothing happens should the user already exist. - .Create user if not exists ====== - -[source, cypher, role=noplay, indent=0] +[source,cypher,role=noplay] ---- CREATE USER jake IF NOT EXISTS SET PLAINTEXT PASSWORD 'xyz' ---- - ====== The `CREATE OR REPLACE USER` command will result in any existing user being deleted and a new one created. - .Create or replace user ====== - -[source, cypher, role=noplay, indent=0] +[source,cypher,role=noplay] ---- CREATE OR REPLACE USER jake SET PLAINTEXT PASSWORD 'xyz' ---- This is equivalent to running `DROP USER jake IF EXISTS` followed by `CREATE USER jake SET PASSWORD 'xyz'`. - ====== [NOTE] ==== -The `CREATE OR REPLACE USER` command does not allow you to use the `IF NOT EXISTS`. +The `CREATE OR REPLACE USER` command does not allow the use of `IF NOT EXISTS`. ==== [[access-control-rename-users]] == Renaming users -Users can be renamed using the `RENAME USER` command. +Users can be renamed with the `RENAME USER` command. -[source, cypher, role=noplay, indent=0] +[source, cypher, role=noplay] ---- RENAME USER jake TO bob ---- -[source, cypher, role=noplay, indent=0] +[source, cypher, role=noplay] ---- SHOW USERS ---- @@ -641,7 +557,11 @@ SHOW USERS .Result [options="header,footer", width="100%", cols="2m,3m,3m,2m,2m"] |=== -|user |roles |passwordChangeRequired |suspended |home +|user +|roles +|passwordChangeRequired +|suspended +|home |"bob" |["PUBLIC"] @@ -656,7 +576,6 @@ SHOW USERS | 5+a|Rows: 2 - |=== [NOTE] @@ -668,9 +587,9 @@ The `RENAME USER` command is only available when using native authentication and [[access-control-alter-users]] == Modifying users -Users can be modified using `ALTER USER`. +Users can be modified with `ALTER USER`. -[source, syntax, role="noheader", indent=0] +[source, cypher, role=noplay] ---- ALTER USER name [IF EXISTS] [SET [PLAINTEXT | ENCRYPTED] PASSWORD 'password'] @@ -683,17 +602,17 @@ ALTER USER name [IF EXISTS] * At least one `SET` or `REMOVE` clause is required for the command. * `SET` and `REMOVE` clauses cannot be combined in the same command. * The `SET PASSWORD CHANGE [NOT] REQUIRED`, `SET STATUS`, and `SET HOME DATABASE` clauses can be applied in any order. -The `SET PASSWORD` clause must come first if used. +The `SET PASSWORD` clause must come first, if used. * For `SET PASSWORD`: ** The `password` can either be a string value or a string parameter. ** All passwords are encrypted (hashed) when stored in the Neo4j `system` database. -`PLAINTEXT` and `ENCRYPTED` just refer to the format of the password in the Cypher command, i.e., whether Neo4j needs to hash it or it has already been hashed. -Therefore, it is never possible to get the plaintext of a password back out of the database. +`PLAINTEXT` and `ENCRYPTED` just refer to the format of the password in the Cypher command, i.e. whether Neo4j needs to hash it or it has already been hashed. +Consequently, it is never possible to get the plaintext of a password back out of the database. A password can be set in either fashion at any time. ** The optional `PLAINTEXT` in `SET PLAINTEXT PASSWORD` has the same behavior as `SET PASSWORD`. ** The optional `ENCRYPTED` is used to update an existing user's password when the plaintext password is unknown, but the encrypted password is available in the _data/scripts/databasename/restore_metadata.cypher_ file of a database backup. -See xref:4.4@operations-manual:ROOT:backup-restore/restore-backup/index.adoc#restore-backup-example[Operations Manual -> Restore a database backup -> Example]. + -With `ENCRYPTED`, the password string is expected to be in the format of `,,`, where, for example: +See < Restore a database backup -> Example>>. + +With `ENCRYPTED`, the password string is expected to be in the format of `,` or ```, where, for example: *** `0` is the first version and refers to the `SHA-256` cryptographic hash function with iterations `1`. *** `1` is the second version and refers to the `SHA-256` cryptographic hash function with iterations `1024`. * If the optional `SET PASSWORD CHANGE [NOT] REQUIRED` is omitted, the default is `CHANGE REQUIRED`. @@ -707,32 +626,28 @@ This results in the DBMS default database being used as the home database for th For example, you can modify the user `bob` with a new password and active status, and remove the requirement to change his password: -[source, cypher, role=noplay, indent=0] +[source, cypher, role=noplay] ---- -ALTER USER bob -SET PASSWORD 'abc123' CHANGE NOT REQUIRED -SET STATUS ACTIVE +ALTER USER bob SET PASSWORD 'abc123' CHANGE NOT REQUIRED SET STATUS ACTIVE ---- -Or, you may decide to assign the user `bob` a different home database: +Or you may decide to assign the user `bob` a different home database: -[source, cypher, role=noplay, indent=0] +[source, cypher, role=noplay] ---- -ALTER USER bob -SET HOME DATABASE anotherDbOrAlias +ALTER USER bob SET HOME DATABASE anotherDbOrAlias ---- -Or, remove the home database from the user `bob`: +Or remove the home database from the user `bob`: -[source, cypher, role=noplay, indent=0] +[source, cypher, role=noplay] ---- -ALTER USER bob -REMOVE HOME DATABASE +ALTER USER bob REMOVE HOME DATABASE ---- [NOTE] ==== -When altering a user it is only necessary to specify the changes required. +When altering a user, it is only necessary to specify the changes required. For example, leaving out the `CHANGE [NOT] REQUIRED` part of the query will leave that unchanged. ==== @@ -743,7 +658,7 @@ The `SET STATUS {ACTIVE | SUSPENDED}`, `SET HOME DATABASE`, and `REMOVE HOME DAT The changes to the user will appear on the list provided by `SHOW USERS`: -[source, cypher, role=noplay, indent=0] +[source, cypher, role=noplay] ---- SHOW USERS ---- @@ -751,7 +666,11 @@ SHOW USERS .Result [options="header,footer", width="100%", cols="2m,3m,3m,2m,2m"] |=== -|user |roles |passwordChangeRequired |suspended |home +|user +|roles +|passwordChangeRequired +|suspended +|home |"bob" |["PUBLIC"] @@ -766,13 +685,13 @@ SHOW USERS | 5+a|Rows: 2 - |=== The default behavior of this command is to throw an exception if the user does not exist. -Appending an optional parameter `IF EXISTS` to the command makes it idempotent and ensures that no exception is thrown and nothing happens should the user not exist. +Adding an optional parameter `IF EXISTS` to the command makes it idempotent and ensures that no exception is thrown. +Nothing happens should the user not exist. -[source, cypher, role=noplay, indent=0] +[source, cypher, role=noplay] ---- ALTER USER nonExistingUser IF EXISTS SET PASSWORD 'abc123' ---- @@ -785,10 +704,9 @@ Users can change their password using `ALTER CURRENT USER SET PASSWORD`. The old password is required in addition to the new one, and either or both can be a string value or a string parameter. When a user executes this command it will change their password as well as set the `CHANGE NOT REQUIRED` flag. -[source, cypher, role=noplay, indent=0] +[source, cypher, role=noplay] ---- -ALTER CURRENT USER -SET PASSWORD FROM 'abc123' TO '123xyz' +ALTER CURRENT USER SET PASSWORD FROM 'abc123' TO '123xyz' ---- [NOTE] @@ -800,18 +718,18 @@ This command works only for a logged-in user and cannot be run with auth disable [[access-control-drop-users]] == Delete users -Users can be deleted using `DROP USER`. +Users can be deleted with `DROP USER`. -[source, cypher, role=noplay, indent=0] +[source, cypher, role=noplay] ---- DROP USER bob ---- Deleting a user will not automatically terminate associated connections, sessions, transactions, or queries. -When a user has been deleted, it will no longer appear on the list provided by `SHOW USERS`: +However, when a user has been deleted, it will no longer appear on the list provided by `SHOW USERS`: -[source, cypher, role=noplay, indent=0] +[source, cypher, role=noplay] ---- SHOW USERS ---- @@ -819,7 +737,11 @@ SHOW USERS .Result [options="header,footer", width="100%", cols="2m,3m,3m,2m,2m"] |=== -|user |roles |passwordChangeRequired |suspended |home +|user +|roles +|passwordChangeRequired +|suspended +|home |"neo4j" |["admin","PUBLIC"] @@ -828,6 +750,4 @@ SHOW USERS | 5+a|Rows: 1 - |=== - diff --git a/modules/ROOT/pages/access-control/privileges-reads.adoc b/modules/ROOT/pages/access-control/privileges-reads.adoc index 5549438e4..2831cc60b 100644 --- a/modules/ROOT/pages/access-control/privileges-reads.adoc +++ b/modules/ROOT/pages/access-control/privileges-reads.adoc @@ -1,5 +1,3 @@ -:description: How to use Cypher to manage read privileges on graphs. - [role=enterprise-edition] [[access-control-privileges-reads]] = Read privileges @@ -11,9 +9,9 @@ This section explains how to use Cypher to manage read privileges on graphs. There are three separate read privileges: -* xref::access-control/privileges-reads.adoc#access-control-privileges-reads-traverse[`TRAVERSE`] - enables the specified entities to be found. -* xref::access-control/privileges-reads.adoc#access-control-privileges-reads-read[`READ`] - enables the specified properties on the found entities to be read. -* xref::access-control/privileges-reads.adoc#access-control-privileges-reads-match[`MATCH`] - combines both `TRAVERSE` and `READ`, enabling an entity to be found and its properties read. +* <> - enables the specified entities to be found. +* <> - enables the specified properties of the found entities to be read. +* <> - combines both `TRAVERSE` and `READ`, enabling an entity to be found and its properties read. [[access-control-privileges-reads-traverse]] @@ -21,42 +19,42 @@ There are three separate read privileges: Users can be granted the right to find nodes and relationships using the `GRANT TRAVERSE` privilege. -[source, syntax, role="noheader", indent=0] +[source, cypher, role=noplay] ---- GRANT TRAVERSE - ON { HOME GRAPH | GRAPH[S] { * | name[, ...] } } - [ - ELEMENT[S] { * | label-or-rel-type[, ...] } - | NODE[S] { * | label[, ...] } - | RELATIONSHIP[S] { * | rel-type[, ...] } - ] - TO role[, ...] + ON {HOME GRAPH | GRAPH[S] { * | name[, ...] }} + [ + ELEMENT[S] { * | label-or-rel-type[, ...] } + | NODE[S] { * | label[, ...] } + | RELATIONSHIP[S] { * | rel-type[, ...] } + ] + TO role[, ...] ---- -For example, we can enable the user `jake`, who has role `regularUsers` to find all nodes with the label `Post`. +For example, we can enable the user `jake`, who has the role 'regularUsers' to find all nodes with the label `Post`: -[source, cypher, role=noplay, indent=0] +[source, cypher, role=noplay] ---- GRANT TRAVERSE ON GRAPH neo4j NODES Post TO regularUsers ---- The `TRAVERSE` privilege can also be denied. -[source, syntax, role="noheader", indent=0] +[source, cypher, role=noplay] ---- DENY TRAVERSE - ON { HOME GRAPH | GRAPH[S] { * | name[, ...] } } - [ - ELEMENT[S] { * | label-or-rel-type[, ...] } - | NODE[S] { * | label[, ...] } - | RELATIONSHIP[S] { * | rel-type[, ...] } - ] - TO role[, ...] + ON {HOME GRAPH | GRAPH[S] { * | name[, ...] }} + [ + ELEMENT[S] { * | label-or-rel-type[, ...] } + | NODE[S] { * | label[, ...] } + | RELATIONSHIP[S] { * | rel-type[, ...] } + ] + TO role[, ...] ---- -For example, we can disable the user `jake`, who has role `regularUsers` from finding all nodes with the label `Payments`. +For example, we can disable the user `jake`, who has the role 'regularUsers' from finding all nodes with the label `Payments`: -[source, cypher, role=noplay, indent=0] +[source, cypher, role=noplay] ---- DENY TRAVERSE ON HOME GRAPH NODES Payments TO regularUsers ---- @@ -68,22 +66,23 @@ DENY TRAVERSE ON HOME GRAPH NODES Payments TO regularUsers Users can be granted the right to do property reads on nodes and relationships using the `GRANT READ` privilege. It is very important to note that users can only read properties on entities that they are enabled to find in the first place. -[source, syntax, role="noheader", indent=0] +[source, cypher, role=noplay] ---- -GRANT READ "{" { * | property[, ...] } "}" - ON { HOME GRAPH | GRAPH[S] { * | name[, ...] } } - [ - ELEMENT[S] { * | label-or-rel-type[, ...] } - | NODE[S] { * | label[, ...] } - | RELATIONSHIP[S] { * | rel-type[, ...] } - ] - TO role[, ...] +GRANT READ + "{" { * | property[, ...] } "}" + ON {HOME GRAPH | GRAPH[S] { * | name[, ...] }} + [ + ELEMENT[S] { * | label-or-rel-type[, ...] } + | NODE[S] { * | label[, ...] } + | RELATIONSHIP[S] { * | rel-type[, ...] } + ] + TO role[, ...] ---- -For example, we can enable the user `jake`, who has role `regularUsers` to read all properties on nodes with the label `Post`. -The `+*+` implies that the ability to read all properties also extends to properties that might be added in the future. +For example, we can enable the user `jake`, who has the role 'regularUsers' to read all properties on nodes with the label `Post`. +The `*` implies that the ability to read all properties also extends to properties that might be added in the future. -[source, cypher, role=noplay, indent=0] +[source, cypher, role=noplay] ---- GRANT READ { * } ON GRAPH neo4j NODES Post TO regularUsers ---- @@ -96,22 +95,23 @@ For example, if there is also a `DENY TRAVERSE` present on the same entity as a The `READ` privilege can also be denied. -[source, syntax, role="noheader", indent=0] +[source, cypher, role=noplay] ---- -DENY READ "{" { * | property[, ...] } "}" - ON { HOME GRAPH | GRAPH[S] { * | name[, ...] } } - [ - ELEMENT[S] { * | label-or-rel-type[, ...] } - | NODE[S] { * | label[, ...] } - | RELATIONSHIP[S] { * | rel-type[, ...] } - ] - TO role[, ...] +DENY READ + "{" { * | property[, ...] } "}" + ON {HOME GRAPH | GRAPH[S] { * | name[, ...] }} + [ + ELEMENT[S] { * | label-or-rel-type[, ...] } + | NODE[S] { * | label[, ...] } + | RELATIONSHIP[S] { * | rel-type[, ...] } + ] + TO role[, ...] ---- Although we just granted the user `jake` the right to read all properties, we may want to hide the `secret` property. -The following example shows how to do that. +The following example shows how to do that: -[source, cypher, role=noplay, indent=0] +[source, cypher, role=noplay] ---- DENY READ { secret } ON GRAPH neo4j NODES Post TO regularUsers ---- @@ -120,60 +120,61 @@ DENY READ { secret } ON GRAPH neo4j NODES Post TO regularUsers [[access-control-privileges-reads-match]] == The `MATCH` privilege -Users can be granted the right to find and do property reads on nodes and relationships using the `GRANT MATCH` privilege +Users can be granted the right to find and do property reads on nodes and relationships using the `GRANT MATCH` privilege. This is semantically the same as having both `TRAVERSE` and `READ` privileges. -[source, syntax, role="noheader", indent=0] +[source, cypher, role=noplay] ---- -GRANT MATCH "{" { * | property[, ...] } "}" - ON { HOME GRAPH | GRAPH[S] { * | name[, ...] } } - [ - ELEMENT[S] { * | label-or-rel-type[, ...] } - | NODE[S] { * | label[, ...] } - | RELATIONSHIP[S] { * | rel-type[, ...] } - ] - TO role[, ...] +GRANT MATCH + "{" { * | property[, ...] } "}" + ON {HOME GRAPH | GRAPH[S] { * | name[, ...] }} + [ + ELEMENT[S] { * | label-or-rel-type[, ...] } + | NODE[S] { * | label[, ...] } + | RELATIONSHIP[S] { * | rel-type[, ...] } + ] + TO role[, ...] ---- -For example if you want to grant the ability to read the properties `language` and `length` for nodes with the label `Message`, as well as the ability to find these nodes, to a role `regularUsers` you can use the following `GRANT MATCH` query. +For example if you want to grant the ability to read the properties `language` and `length` for nodes with the label `Message`, as well as the ability to find these nodes to the role `regularUsers`, you can use the following `GRANT MATCH` query: -[source, cypher, role=noplay, indent=0] +[source, cypher, role=noplay] ---- GRANT MATCH { language, length } ON GRAPH neo4j NODES Message TO regularUsers ---- Like all other privileges, the `MATCH` privilege can also be denied. -[source, syntax, role="noheader", indent=0] +[source, cypher, role=noplay] ---- -DENY MATCH "{" { * | property[, ...] } "}" - ON { HOME GRAPH | GRAPH[S] { * | name[, ...] } } - [ - ELEMENT[S] { * | label-or-rel-type[, ...] } - | NODE[S] { * | label[, ...] } - | RELATIONSHIP[S] { * | rel-type[, ...] } - ] - TO role[, ...] +DENY MATCH + "{" { * | property[, ...] } "}" + ON {HOME GRAPH | GRAPH[S] { * | name[, ...] }} + [ + ELEMENT[S] { * | label-or-rel-type[, ...] } + | NODE[S] { * | label[, ...] } + | RELATIONSHIP[S] { * | rel-type[, ...] } + ] + TO role[, ...] ---- -Please note that the effect of denying a `MATCH` privilege depends on whether concrete property keys are specified or a `+*+`. -If you specify concrete property keys then `DENY MATCH` will only deny reading those properties. +Please note that the effect of denying a `MATCH` privilege depends on whether concrete property keys are specified or are `+*+`. +If you specify concrete property keys, then `DENY MATCH` will only deny reading those properties. Finding the elements to traverse would still be enabled. -If you specify `+*+` instead then both traversal of the element and all property reads will be disabled. +If you specify `+*+` instead, then both traversal of the element and all property reads will be disabled. The following queries will show examples for this. -Denying to read the property ´content´ on nodes with the label `Message` for the role `regularUsers` would look like the following query. +Denying to read the property `content` on nodes with the label `Message` for the role `regularUsers` would look like the following query. Although not being able to read this specific property, nodes with that label can still be traversed (and, depending on other grants, other properties on it could still be read). -[source, cypher, role=noplay, indent=0] +[source, cypher, role=noplay] ---- DENY MATCH { content } ON GRAPH neo4j NODES Message TO regularUsers ---- -The following query exemplifies how it would look like if you want to deny both reading all properties and traversing nodes labeled with `Account`. +The following query exemplifies how it would look if you wanted to deny both reading all properties and traversing nodes labeled with `Account`: -[source, cypher, role=noplay, indent=0] +[source, cypher, role=noplay] ---- DENY MATCH { * } ON GRAPH neo4j NODES Account TO regularUsers ---- - diff --git a/modules/ROOT/pages/access-control/privileges-writes.adoc b/modules/ROOT/pages/access-control/privileges-writes.adoc index 59a9f0a0b..bf73f1e3d 100644 --- a/modules/ROOT/pages/access-control/privileges-writes.adoc +++ b/modules/ROOT/pages/access-control/privileges-writes.adoc @@ -1,5 +1,3 @@ -:description: How to use Cypher to manage write privileges on graphs. - [role=enterprise-edition] [[access-control-privileges-writes]] = Write privileges @@ -11,114 +9,110 @@ This section explains how to use Cypher to manage write privileges on graphs. Write privileges are defined for different parts of the graph: -* xref::access-control/privileges-writes.adoc#access-control-privileges-writes-create[`CREATE`] - allows creating nodes and relationships. -* xref::access-control/privileges-writes.adoc#access-control-privileges-writes-delete[`DELETE`] - allows deleting nodes and relationships. -* xref::access-control/privileges-writes.adoc#access-control-privileges-writes-set-label[`SET LABEL`] - allows setting the specified node labels using the `SET` clause. -* xref::access-control/privileges-writes.adoc#access-control-privileges-writes-remove-label[`REMOVE LABEL`] - allows removing the specified node labels using the `REMOVE` clause. -* xref::access-control/privileges-writes.adoc#access-control-privileges-writes-set-property[`SET PROPERTY`] - allows setting properties on nodes and relationships. +* <> - allows creating nodes and relationships. +* <> - allows deleting nodes and relationships. +* <> - allows setting the specified node labels using the `SET` clause. +* <> - allows removing the specified node labels using the `REMOVE` clause. +* <> - allows setting properties on nodes and relationships. There are also compound privileges which combine the above specific privileges: -* xref::access-control/privileges-writes.adoc#access-control-privileges-writes-merge[`MERGE`] - allows match, create and set property to permit the `MERGE` command. -* xref::access-control/privileges-writes.adoc#access-control-privileges-writes-write[`WRITE`] - allows all write operations on an entire graph. -* xref::access-control/privileges-writes.adoc#access-control-privileges-writes-all[`ALL GRAPH PRIVILEGES`] - allows all read and write operation on an entire graph. +* <> - allows `MATCH`, `CREATE` and `SET PROPERTY` to apply the `MERGE` command. +* <> - allows all `WRITE` operations on an entire graph. +* <> - allows all `READ` and `WRITE` operations on an entire graph. [[access-control-privileges-writes-create]] == The `CREATE` privilege -The `CREATE` privilege allows a user to create new node and relationship elements in a graph. -See the Cypher xref::clauses/create.adoc[CREATE] clause. +The `CREATE` privilege allows a user to create new node and relationship elements on a graph. +See the Cypher <> clause. -[source, syntax, role="noheader", indent=0] +[source, cypher, role=noplay] ---- -GRANT CREATE - ON { HOME GRAPH | GRAPH[S] { * | name[, ...] } } +GRANT CREATE ON {HOME GRAPH | GRAPH[S] { * | name[, ...] }} [ - ELEMENT[S] { * | label-or-rel-type[, ...] } - | NODE[S] { * | label[, ...] } - | RELATIONSHIP[S] { * | rel-type[, ...] } + ELEMENT[S] { * | label-or-rel-type[, ...] } + | NODE[S] { * | label[, ...] } + | RELATIONSHIP[S] { * | rel-type[, ...] } ] - TO role[, ...] + TO role[, ...] ---- -For example, granting the ability to create elements on the graph `neo4j` to the role `regularUsers` would be achieved using: +For example, to grant the role `regularUsers` the ability to `CREATE` elements on the graph `neo4j`, use: -[source, cypher, role=noplay, indent=0] +[source, cypher, role=noplay] ---- GRANT CREATE ON GRAPH neo4j ELEMENTS * TO regularUsers ---- -The `CREATE` privilege can also be denied. +The `CREATE` privilege can also be denied: -[source, syntax, role="noheader", indent=0] +[source, cypher, role=noplay] ---- -DENY CREATE - ON { HOME GRAPH | GRAPH[S] { * | name[, ...] } } +DENY CREATE ON {HOME GRAPH | GRAPH[S] { * | name[, ...] }} [ - ELEMENT[S] { * | label-or-rel-type[, ...] } - | NODE[S] { * | label[, ...] } - | RELATIONSHIP[S] { * | rel-type[, ...] } + ELEMENT[S] { * | label-or-rel-type[, ...] } + | NODE[S] { * | label[, ...] } + | RELATIONSHIP[S] { * | rel-type[, ...] } ] - TO role[, ...] + TO role[, ...] ---- -For example, denying the ability to create nodes with the label `foo` on all graphs to the role `regularUsers` would be achieved using: +For example, to deny the role `regularUsers` the ability to `CREATE` nodes with the label `foo` on all graphs, use: -[source, cypher, role=noplay, indent=0] +[source, cypher, role=noplay] ---- DENY CREATE ON GRAPH * NODES foo TO regularUsers ---- [NOTE] ==== -If the user attempts to create nodes with a label that does not already exist in the database, then the user must also possess the xref::access-control/database-administration.adoc#access-control-database-administration-tokens[CREATE NEW LABEL] privilege. -The same applies to new relationships - the xref::access-control/database-administration.adoc#access-control-database-administration-tokens[CREATE NEW RELATIONSHIP TYPE] privilege is required. +If the user attempts to create nodes with a label that does not already exist on the database, then the user must also possess the <> privilege. +The same applies to new relationships: the <> privilege is required. ==== [[access-control-privileges-writes-delete]] == The `DELETE` privilege -The `DELETE` privilege allows a user to delete node and relationship elements in a graph. -See the Cypher xref::clauses/delete.adoc[DELETE] clause. +The `DELETE` privilege allows a user to delete node and relationship elements on a graph. +See the Cypher <> clause. -[source, syntax, role="noheader", indent=0] +[source, cypher, role=noplay] ---- -GRANT DELETE - ON { HOME GRAPH | GRAPH[S] { * | name[, ...] } } +GRANT DELETE ON {HOME GRAPH | GRAPH[S] { * | name[, ...] }} [ - ELEMENT[S] { * | label-or-rel-type[, ...] } - | NODE[S] { * | label[, ...] } - | RELATIONSHIP[S] { * | rel-type[, ...] } + ELEMENT[S] { * | label-or-rel-type[, ...] } + | NODE[S] { * | label[, ...] } + | RELATIONSHIP[S] { * | rel-type[, ...] } ] - TO role[, ...] + TO role[, ...] ---- -For example, granting the ability to delete elements on the graph `neo4j` to the role `regularUsers` would be achieved using: +For example, to grant the role `regularUsers` the ability to `DELETE` elements on the graph `neo4j`, use: -[source, cypher, role=noplay, indent=0] +[source, cypher, role=noplay] ---- GRANT DELETE ON GRAPH neo4j ELEMENTS * TO regularUsers ---- -The `DELETE` privilege can also be denied. +The `DELETE` privilege can also be denied: -[source, syntax, role="noheader", indent=0] +[source, cypher, role=noplay] ---- -DENY DELETE - ON { HOME GRAPH | GRAPH[S] { * | name[, ...] } } +DENY DELETE ON {HOME GRAPH | GRAPH[S] { * | name[, ...] }} [ - ELEMENT[S] { * | label-or-rel-type[, ...] } - | NODE[S] { * | label[, ...] } - | RELATIONSHIP[S] { * | rel-type[, ...] } + ELEMENT[S] { * | label-or-rel-type[, ...] } + | NODE[S] { * | label[, ...] } + | RELATIONSHIP[S] { * | rel-type[, ...] } ] - TO role[, ...] + TO role[, ...] ---- -For example, denying the ability to delete relationships with the relationship type `bar` on all graphs to the role `regularUsers` would be achieved using: +For example, to deny the role `regularUsers` the ability to `DELETE` relationships with the relationship type `bar` on all graphs, use: -[source, cypher, role=noplay, indent=0] +[source, cypher, role=noplay] ---- DENY DELETE ON GRAPH * RELATIONSHIPS bar TO regularUsers ---- @@ -126,92 +120,92 @@ DENY DELETE ON GRAPH * RELATIONSHIPS bar TO regularUsers [NOTE] ==== Users with `DELETE` privilege, but restricted `TRAVERSE` privileges, will not be able to do `DETACH DELETE` in all cases. -See xref:4.4@operations-manual:ROOT:authentication-authorization/access-control/index.adoc#detach-delete-restricted-user[Operations Manual -> Fine-grained access control] for more info. +See < Fine-grained access control>> for more info. ==== [[access-control-privileges-writes-set-label]] == The `SET LABEL` privilege -The `SET LABEL` privilege allows you to set labels on a node using the xref::clauses/set.adoc#set-set-a-label-on-a-node[SET clause]. +The `SET LABEL` privilege allows you to set labels on a node by using the <>: -[source, syntax, role="noheader", indent=0] +[source, cypher, role=noplay] ---- GRANT SET LABEL { * | label[, ...] } - ON { HOME GRAPH | GRAPH[S] { * | name[, ...] } } - TO role[, ...] + ON {HOME GRAPH | GRAPH[S] { * | name[, ...] }} + TO role[, ...] ---- -For example, granting the ability to set any label on nodes of the graph `neo4j` to the role `regularUsers` would be achieved using: +For example, to grant the role `regularUsers` the ability to `SET` any label on nodes of the graph `neo4j`, use: -[source, cypher, role=noplay, indent=0] +[source, cypher, role=noplay] ---- GRANT SET LABEL * ON GRAPH neo4j TO regularUsers ---- [NOTE] ==== -Unlike many of the other read and write privileges, it is not possible to restrict the `SET LABEL` privilege to specific +ELEMENTS+, +NODES+, or +RELATIONSHIPS+. +Unlike many of the other `READ` and `WRITE` privileges, it is not possible to restrict the `SET LABEL` privilege to specific ELEMENTS, NODES or RELATIONSHIPS. ==== -The `SET LABEL` privilege can also be denied. +The `SET LABEL` privilege can also be denied: -[source, syntax, role="noheader", indent=0] +[source, cypher, role=noplay] ---- DENY SET LABEL { * | label[, ...] } - ON { HOME GRAPH | GRAPH[S] { * | name[, ...] } } - TO role[, ...] + ON {HOME GRAPH | GRAPH[S] { * | name[, ...] }} + TO role[, ...] ---- -For example, denying the ability to set the label `foo` on nodes of all graphs to the role `regularUsers` would be achieved using: +For example, to deny the role `regularUsers` the ability to `SET` the label `foo` on nodes of all graphs, use: -[source, cypher, role=noplay, indent=0] +[source, cypher, role=noplay] ---- DENY SET LABEL foo ON GRAPH * TO regularUsers ---- [NOTE] ==== -If no instances of this label exist in the database, then the xref::access-control/database-administration.adoc#access-control-database-administration-tokens[CREATE NEW LABEL] privilege is also required. +If no instances of this label exist on the database, then the <> privilege is also required. ==== [[access-control-privileges-writes-remove-label]] == The `REMOVE LABEL` privilege -The `REMOVE LABEL` privilege allows you to remove labels from a node using the xref::clauses/remove.adoc#remove-remove-a-label-from-a-node[REMOVE clause]. +The `REMOVE LABEL` privilege allows you to remove labels from a node by using the <>: -[source, syntax, role="noheader", indent=0] +[source, cypher, role=noplay] ---- GRANT REMOVE LABEL { * | label[, ...] } - ON { HOME GRAPH | GRAPH[S] { * | name[, ...] } } - TO role[, ...] + ON {HOME GRAPH | GRAPH[S] { * | name[, ...] }} + TO role[, ...] ---- -For example, granting the ability to remove any label from nodes of the graph `neo4j` to the role `regularUsers` would be achieved using: +For example, to grant the role `regularUsers` the ability to `REMOVE` any label from nodes of the graph `neo4j`, use: -[source, cypher, role=noplay, indent=0] +[source, cypher, role=noplay] ---- GRANT REMOVE LABEL * ON GRAPH neo4j TO regularUsers ---- [NOTE] ==== -Unlike many of the other read and write privileges, it is not possible to restrict the `REMOVE LABEL` privilege to specific +ELEMENTS+, +NODES+, or +RELATIONSHIPS+. +Unlike many of the other `READ` and `WRITE` privileges, it is not possible to restrict the `REMOVE LABEL` privilege to specific ELEMENTS, NODES or RELATIONSHIPS. ==== -The `REMOVE LABEL` privilege can also be denied. +The `REMOVE LABEL` privilege can also be denied: -[source, syntax, role="noheader", indent=0] +[source, cypher, role=noplay] ---- DENY REMOVE LABEL { * | label[, ...] } - ON { HOME GRAPH | GRAPH[S] { * | name[, ...] } } - TO role[, ...] + ON {HOME GRAPH | GRAPH[S] { * | name[, ...] }} + TO role[, ...] ---- -For example, denying the ability to remove the label `foo` from nodes of all graphs to the role `regularUsers` would be achieved using: +For example, denying the role `regularUsers` the ability to remove the label `foo` from nodes of all graphs, use: -[source, cypher, role=noplay, indent=0] +[source, cypher, role=noplay] ---- DENY REMOVE LABEL foo ON GRAPH * TO regularUsers ---- @@ -220,51 +214,51 @@ DENY REMOVE LABEL foo ON GRAPH * TO regularUsers [[access-control-privileges-writes-set-property]] == The `SET PROPERTY` privilege -The `SET PROPERTY` privilege allows a user to set a property on a node or relationship element in a graph using the xref::clauses/set.adoc#set-set-a-property[SET clause]. +The `SET PROPERTY` privilege allows a user to set a property on a node or relationship element in a graph by using the <>: -[source, syntax, role="noheader", indent=0] +[source, cypher, role=noplay] ---- GRANT SET PROPERTY "{" { * | property[, ...] } "}" - ON { HOME GRAPH | GRAPH[S] { * | name[, ...] } } - [ - ELEMENT[S] { * | label-or-rel-type[, ...] } - | NODE[S] { * | label[, ...] } - | RELATIONSHIP[S] { * | rel-type[, ...] } - ] - TO role[, ...] + ON {HOME GRAPH | GRAPH[S] { * | name[, ...] }} + [ + ELEMENT[S] { * | label-or-rel-type[, ...] } + | NODE[S] { * | label[, ...] } + | RELATIONSHIP[S] { * | rel-type[, ...] } + ] + TO role[, ...] ---- -For example, granting the ability to set any property on all elements of the graph `neo4j` to the role `regularUsers` would be achieved using: +For example, to grant the role `regularUsers` the ability to `SET` any property on all elements of the graph `neo4j`, use: -[source, cypher, role=noplay, indent=0] +[source, cypher, role=noplay] ---- GRANT SET PROPERTY {*} ON HOME GRAPH ELEMENTS * TO regularUsers ---- -The `SET PROPERTY` privilege can also be denied. +The `SET PROPERTY` privilege can also be denied: -[source, syntax, role="noheader", indent=0] +[source, cypher, role=noplay] ---- DENY SET PROPERTY "{" { * | property[, ...] } "}" - ON { HOME GRAPH | GRAPH[S] { * | name[, ...] } } - [ - ELEMENT[S] { * | label-or-rel-type[, ...] } - | NODE[S] { * | label[, ...] } - | RELATIONSHIP[S] { * | rel-type[, ...] } - ] - TO role[, ...] + ON {HOME GRAPH | GRAPH[S] { * | name[, ...] }} + [ + ELEMENT[S] { * | label-or-rel-type[, ...] } + | NODE[S] { * | label[, ...] } + | RELATIONSHIP[S] { * | rel-type[, ...] } + ] + TO role[, ...] ---- -For example, denying the ability to set the property `foo` on nodes with the label `bar` on all graphs to the role `regularUsers` would be achieved using: +For example, to deny the role `regularUsers` the ability to `SET` the property `foo` on nodes with the label `bar` on all graphs, use: -[source, cypher, role=noplay, indent=0] +[source, cypher, role=noplay] ---- DENY SET PROPERTY { foo } ON GRAPH * NODES bar TO regularUsers ---- [NOTE] ==== -If the users attempts to set a property with a property name that does not already exist in the database the user must also possess the xref::access-control/database-administration.adoc#access-control-database-administration-tokens[CREATE NEW PROPERTY NAME] privilege. +If the user attempts to set a property with a property name that does not already exist on the database, the user must also possess the <> privilege. ==== @@ -272,77 +266,77 @@ If the users attempts to set a property with a property name that does not alrea == The `MERGE` privilege The `MERGE` privilege is a compound privilege that combines `TRAVERSE` and `READ` (i.e. `MATCH`) with `CREATE` and `SET PROPERTY`. -This is intended to permit use of xref::clauses/merge.adoc[the MERGE command] but is applicable to all reads and writes that require these privileges. +This is intended to enable the use of <>, but it is also applicable to all reads and writes that require these privileges. -[source, syntax, role="noheader", indent=0] +[source, cypher, role=noplay] ---- GRANT MERGE "{" { * | property[, ...] } "}" - ON { HOME GRAPH | GRAPH[S] { * | name[, ...] } } - [ - ELEMENT[S] { * | label-or-rel-type[, ...] } - | NODE[S] { * | label[, ...] } - | RELATIONSHIP[S] { * | rel-type[, ...] } - ] - TO role[, ...] + ON {HOME GRAPH | GRAPH[S] { * | name[, ...] }} + [ + ELEMENT[S] { * | label-or-rel-type[, ...] } + | NODE[S] { * | label[, ...] } + | RELATIONSHIP[S] { * | rel-type[, ...] } + ] + TO role[, ...] ---- -For example, granting `MERGE` on all elements of the graph `neo4j` to the role `regularUsers` would be achieved using: +For example, to grant the role `regularUsers` the ability to `MERGE` on all elements of the graph `neo4j`, use: -[source, cypher, role=noplay, indent=0] +[source, cypher, role=noplay] ---- GRANT MERGE {*} ON GRAPH neo4j ELEMENTS * TO regularUsers ---- It is not possible to deny the `MERGE` privilege. -If it is desirable to prevent a users from creating elements and setting properties, use xref::access-control/privileges-writes.adoc#access-control-privileges-writes-create[DENY CREATE] or xref::access-control/privileges-writes.adoc#access-control-privileges-writes-set-property[DENY SET PROPERTY]. +If you wish to prevent a user from creating elements and setting properties: use <> or <>. [NOTE] ==== -If the users attempts to create nodes with a label that does not already exist in the database the user must also possess the -xref::access-control/database-administration.adoc#access-control-database-administration-tokens[CREATE NEW LABEL] privilege. +If the user attempts to create nodes with a label that does not already exist on the database, the user must also possess the +<> privilege. The same applies to new relationships and properties - the -xref::access-control/database-administration.adoc#access-control-database-administration-tokens[CREATE NEW RELATIONSHIP TYPE] or -xref::access-control/database-administration.adoc#access-control-database-administration-tokens[CREATE NEW PROPERTY NAME] privileges are required. +<> or +<> privileges are required. ==== [[access-control-privileges-writes-write]] == The `WRITE` privilege -The `WRITE` privilege allows the user to execute any write command on a graph. +The `WRITE` privilege allows the user to execute any `WRITE` command on a graph. -[source, syntax, role="noheader", indent=0] +[source, cypher, role=noplay] ---- GRANT WRITE - ON { HOME GRAPH | GRAPH[S] { * | name[, ...] } } - TO role[, ...] + ON {HOME GRAPH | GRAPH[S] { * | name[, ...] }} + TO role[, ...] ---- -For example, granting the ability to write on the graph `neo4j` to the role `regularUsers` would be achieved using: +For example, to grant the role `regularUsers` the ability to `WRITE` on the graph `neo4j`, use: -[source, cypher, role=noplay, indent=0] +[source, cypher, role=noplay] ---- GRANT WRITE ON GRAPH neo4j TO regularUsers ---- [NOTE] ==== -Unlike the more specific write commands, it is not possible to restrict `WRITE` privileges to specific +ELEMENTS+, +NODES+, or +RELATIONSHIPS+. -If it is desirable to prevent a user from writing to a subset of database objects, a `GRANT WRITE` can be combined with more specific `DENY` commands to target these elements. +Unlike the more specific `WRITE` commands, it is not possible to restrict `WRITE` privileges to specific ELEMENTS, NODES or RELATIONSHIPS. +If you wish to prevent a user from writing to a subset of database objects, a `GRANT WRITE` can be combined with more specific `DENY` commands to target these elements. ==== -The `WRITE` privilege can also be denied. +The `WRITE` privilege can also be denied: -[source, syntax, role="noheader", indent=0] +[source, cypher, role=noplay] ---- DENY WRITE - ON { HOME GRAPH | GRAPH[S] { * | name[, ...] } } - TO role[, ...] + ON {HOME GRAPH | GRAPH[S] { * | name[, ...] }} + TO role[, ...] ---- -For example, denying the ability to write on the graph `neo4j` to the role `regularUsers` would be achieved using: +For example, to deny the role `regularUsers` the ability to `WRITE` on the graph `neo4j`, use: -[source, cypher, role=noplay, indent=0] +[source, cypher, role=noplay] ---- DENY WRITE ON GRAPH neo4j TO regularUsers ---- @@ -350,48 +344,48 @@ DENY WRITE ON GRAPH neo4j TO regularUsers [NOTE] ==== Users with `WRITE` privilege but restricted `TRAVERSE` privileges will not be able to do `DETACH DELETE` in all cases. -See xref:4.4@operations-manual:ROOT:authentication-authorization/access-control/index.adoc#detach-delete-restricted-user[Operations Manual -> Fine-grained access control] for more info. +See < Fine-grained access control>> for more info. ==== [[access-control-privileges-writes-all]] == The `ALL GRAPH PRIVILEGES` privilege -The `ALL GRAPH PRIVILEGES` privilege allows the user to execute any command on a graph. +The `ALL GRAPH PRIVILEGES` privilege allows the user to execute any command on a graph: -[source, syntax, role="noheader", indent=0] +[source, cypher, role=noplay] ---- GRANT ALL [ [ GRAPH ] PRIVILEGES ] - ON { HOME GRAPH | GRAPH[S] { * | name[, ...] } } - TO role[, ...] + ON {HOME GRAPH | GRAPH[S] { * | name[, ...] }} + TO role[, ...] ---- -For example, granting all graph privileges on the graph `neo4j` to the role `regularUsers` would be achieved using: +For example, to grant the role `regularUsers` `ALL GRAPH PRIVILEGES` on the graph `neo4j`, use: -[source, cypher, role=noplay, indent=0] +[source, cypher, role=noplay] ---- GRANT ALL GRAPH PRIVILEGES ON GRAPH neo4j TO regularUsers ---- [NOTE] ==== -Unlike the more specific read and write commands, it is not possible to restrict `ALL GRAPH PRIVILEGES` privileges to specific +ELEMENTS+, +NODES+, or +RELATIONSHIPS+. -If it is desirable to prevent a user from reading or writing to a subset of database objects, a `GRANT ALL GRAPH PRIVILEGES` can be combined with more specific `DENY` commands to target these elements. +Unlike the more specific `READ` and `WRITE` commands, it is not possible to restrict `ALL GRAPH PRIVILEGES` to specific ELEMENTS, +NODES or RELATIONSHIPS. +If you wish to prevent a user from reading or writing to a subset of database objects, a `GRANT ALL GRAPH PRIVILEGES` can be combined with more specific `DENY` commands to target these elements. ==== -The `ALL GRAPH PRIVILEGES` privilege can also be denied. +The `ALL GRAPH PRIVILEGES` privilege can also be denied: -[source, syntax, role="noheader", indent=0] +[source, cypher, role=noplay] ---- DENY ALL [ [ GRAPH ] PRIVILEGES ] - ON { HOME GRAPH | GRAPH[S] { * | name[, ...] } } - TO role[, ...] + ON {HOME GRAPH | GRAPH[S] { * | name[, ...] }} + TO role[, ...] ---- -For example, denying all graph privileges on the graph `neo4j` to the role `regularUsers` would be achieved using: +For example, to deny the role `regularUsers` all graph privileges on the graph `neo4j`, use: -[source, cypher, role=noplay, indent=0] +[source, cypher, role=noplay] ---- DENY ALL GRAPH PRIVILEGES ON GRAPH neo4j TO regularUsers ---- - From 7890313f9d3932479ec7ae37ed80734c3e88db02 Mon Sep 17 00:00:00 2001 From: lidiazuin <102308961+lidiazuin@users.noreply.github.com> Date: Tue, 26 Jul 2022 10:15:38 +0200 Subject: [PATCH 2/5] reverting changes in links and formatting --- .../pages/access-control/built-in-roles.adoc | 35 ++++++++++--------- 1 file changed, 18 insertions(+), 17 deletions(-) diff --git a/modules/ROOT/pages/access-control/built-in-roles.adoc b/modules/ROOT/pages/access-control/built-in-roles.adoc index 294da2c57..c2022ae4e 100644 --- a/modules/ROOT/pages/access-control/built-in-roles.adoc +++ b/modules/ROOT/pages/access-control/built-in-roles.adoc @@ -1,3 +1,4 @@ +:description: The default privileges of the built-in roles in Neo4j and how to recreate them if needed. [role=enterprise-edition] [[access-control-built-in-roles]] = Built-in roles and privileges @@ -10,12 +11,12 @@ This section explains the default privileges of the built-in roles in Neo4j and All of the commands described in this chapter require that the user executing the commands has the rights to do so. The privileges listed in the following sections are the default set of privileges for each built-in role: -* <> -* <> -* <> -* <> -* <> -* <> +* xref::access-control/built-in-roles.adoc#access-control-built-in-roles-public[The `PUBLIC` role] +* xref::access-control/built-in-roles.adoc#access-control-built-in-roles-reader[The `reader` role] +* xref::access-control/built-in-roles.adoc#access-control-built-in-roles-editor[The `editor` role] +* xref::access-control/built-in-roles.adoc#access-control-built-in-roles-publisher[The `publisher` role] +* xref::access-control/built-in-roles.adoc#access-control-built-in-roles-architect[The `architect` role] +* xref::access-control/built-in-roles.adoc#access-control-built-in-roles-admin[The `admin` role] [[access-control-built-in-roles-public]] == The `PUBLIC` role @@ -183,7 +184,7 @@ The resulting `editor` role now has the same privileges as the original built-in [[access-control-built-in-roles-publisher]] == The `publisher` role -The `publisher` role can do the same as <>, as well as create new labels, property keys and relationship types. +The `publisher` role can do the same as xref::access-control/built-in-roles.adoc#access-control-built-in-roles-editor[`editor`], as well as create new labels, property keys and relationship types. [[access-control-built-in-roles-publisher-list]] @@ -245,7 +246,7 @@ The resulting `publisher` role now has the same privileges as the original built [[access-control-built-in-roles-architect]] == The `architect` role -The `architect` role can do the same as the <>, as well as create and manage indexes and constraints. +The `architect` role can do the same as the xref::access-control/built-in-roles.adoc#access-control-built-in-roles-publisher[`publisher`], as well as create and manage indexes and constraints. [[access-control-built-in-roles-architect-list]] @@ -314,24 +315,24 @@ The resulting `architect` role now has the same privileges as the original built [[access-control-built-in-roles-admin]] == The `admin` role -The `admin` role can do the same as the <>, as well as manage databases, aliases, users, roles and privileges. +The `admin` role can do the same as the xref::access-control/built-in-roles.adoc#access-control-built-in-roles-architect[`architect`], as well as manage databases, aliases, users, roles and privileges. The `admin` role has the ability to perform administrative tasks. These include the rights to perform the following classes of tasks: -* Manage <> to control the rights to perform actions on specific databases: +* Manage xref::access-control/database-administration.adoc[database security] to control the rights to perform actions on specific databases: ** Manage access to a database and the right to start and stop a database. -** Manage <> and <>. +** Manage xref::indexes-for-search-performance.adoc[indexes] and xref::constraints/index.adoc[constraints]. ** Allow the creation of labels, relationship types or property names. ** Manage transactions -* Manage <> to control the rights to perform actions on the entire system: -** Manage <>. -** Manage <> and <>. +* Manage xref::access-control/dbms-administration.adoc[DBMS security] to control the rights to perform actions on the entire system: +** Manage xref::databases.adoc[multiple databases]. +** Manage xref::access-control/manage-users.adoc[users] and xref::access-control/manage-roles.adoc[roles]. ** Change configuration parameters. ** Manage sub-graph privileges. ** Manage procedure security. -These rights are conferred using privileges that can be managed through the <>. +These rights are conferred using privileges that can be managed through the xref::access-control/manage-privileges.adoc#access-control-graph-privileges[`GRANT`, `DENY` and `REVOKE` commands]. [[access-control-built-in-roles-admin-list]] @@ -360,7 +361,7 @@ SHOW ROLE admin PRIVILEGES AS COMMANDS a|Rows: 11 |=== -If the built-in `admin` role has been altered or dropped, and needs to be restored to its original state, see < Password and user recovery>>. +If the built-in `admin` role has been altered or dropped, and needs to be restored to its original state, see xref:4.4@operations-manual:ROOT:configuration/password-and-user-recovery/index.adoc[Operations Manual -> Password and user recovery]. [[access-control-built-in-roles-admin-recreate]] @@ -412,4 +413,4 @@ GRANT ALL ON DATABASE * TO admin The resulting `admin` role now has the same privileges as the original built-in `admin` role. -Additional information about restoring the `admin` role can be found at < Recover the admin role>>. +Additional information about restoring the `admin` role can be found at xref:4.4@operations-manual:ROOT:configuration/password-and-user-recovery/index.adoc#recover-admin-role[Operations Manual -> Recover the admin role]. From 00750b66f98cd0cea89b6b4ca623260ec8271ec4 Mon Sep 17 00:00:00 2001 From: lidiazuin <102308961+lidiazuin@users.noreply.github.com> Date: Tue, 26 Jul 2022 12:09:34 +0200 Subject: [PATCH 3/5] reverting changes in code to fit current format --- .../database-administration.adoc | 721 ++++++++++++++---- 1 file changed, 579 insertions(+), 142 deletions(-) diff --git a/modules/ROOT/pages/access-control/database-administration.adoc b/modules/ROOT/pages/access-control/database-administration.adoc index 30054dcb3..9dae88475 100644 --- a/modules/ROOT/pages/access-control/database-administration.adoc +++ b/modules/ROOT/pages/access-control/database-administration.adoc @@ -1,3 +1,5 @@ +:description: How to use Cypher to manage Neo4j database administrative privileges. + [role=enterprise-edition] [[access-control-database-administration]] = Database administration @@ -54,32 +56,107 @@ This can be quite powerful as it allows permissions to be switched from one data * _role[, ...]_ ** The role or roles to associate the privilege with, comma-separated. -.General database privilege command syntax -[options="header", width="100%", cols="3a,2"] + +.General grant +ON DATABASE+ privilege syntax +[cols="<15s,<85"] |=== -| Command | Description -| [source, cypher, role=noplay] -GRANT database-privilege ON {HOME DATABASE \| DATABASE[S] {* \| name[, ...]}} TO role[, ...] +| Command +m| +GRANT ... ON ... TO ...+ + +| Syntax +a| +[source, syntax, role="noheader", indent=0] +---- +GRANT database-privilege ON { HOME DATABASE \| DATABASE[S] { * \| name[, ...] } } TO role[, ...] +---- + +| Description | Grants a privilege to one or multiple roles. -| [source, cypher, role=noplay] -DENY database-privilege ON {HOME DATABASE \| DATABASE[S] {* \| name[, ...]}} TO role[, ...] +|=== + + +.General deny +ON DATABASE+ privilege syntax +[cols="<15s,<85"] +|=== + +| Command +m| +DENY ... ON ... TO ...+ + +| Syntax +a| +[source, syntax, role="noheader", indent=0] +---- +DENY database-privilege ON { HOME DATABASE \| DATABASE[S] { * \| name[, ...] } } TO role[, ...] +---- + +| Description | Denies a privilege to one or multiple roles. -| [source, cypher, role=noplay] -REVOKE GRANT database-privilege ON {HOME DATABASE \| DATABASE[S] {* \| name[, ...]}} FROM role[, ...] -| Revokes a granted privilege from one or multiple roles. +|=== + + +.General revoke +ON DATABASE+ privilege syntax +[cols="<15s,<85"] +|=== + +| Command +m| +REVOKE DENY ... ON ... FROM ...+ + +| Syntax +a| +[source, syntax, role="noheader", indent=0] +---- +REVOKE DENY database-privilege ON { HOME DATABASE \| DATABASE[S] { * \| name[, ...] } } FROM role[, ...] +---- + +| Description +| Revoke a denied privilege from one or multiple roles. + +|=== + -| [source, cypher, role=noplay] -REVOKE DENY database-privilege ON {HOME DATABASE \| DATABASE[S] {* \| name[, ...]}} FROM role[, ...] +.General revoke +ON DATABASE+ privilege syntax +[cols="<15s,<85"] +|=== + +| Command +m| +REVOKE DENY ... ON ... FROM ...+ + +| Syntax +a| +[source, syntax, role="noheader", indent=0] +---- +REVOKE DENY database-privilege ON { HOME DATABASE \| DATABASE[S] { * \| name[, ...] } } FROM role[, ...] +---- + +| Description | Revokes a denied privilege from one or multiple roles. -| [source, cypher, role=noplay] -REVOKE database-privilege ON {HOME DATABASE \| DATABASE[S] {* \| name[, ...]}} FROM role[, ...] +|=== + + +.General revoke +ON DATABASE+ privilege syntax +[cols="<15s,<85"] +|=== + +| Command +m| +REVOKE ... ON ... FROM ...+ + +| Syntax +a| +[source, syntax, role="noheader", indent=0] +---- +REVOKE database-privilege ON { HOME DATABASE \| DATABASE[S] { * \| name[, ...] } } FROM role[, ...] +---- + +| Description | Revokes a granted or denied privilege from one or multiple roles. + |=== + [NOTE] ==== `DENY` does NOT erase a granted privilege. @@ -88,98 +165,303 @@ Use `REVOKE` if you want to remove a privilege. The hierarchy between the different database privileges is shown in the image below. -image::privilege-hierarchy-database.png[title="Database privileges hierarchy"] +image::privileges_hierarchy_database.png[title="Database privileges hierarchy"] + -.Database privilege command syntax -[options="header", width="100%", cols="3a,2a"] + + +.Database privilege syntax +[cols="<15s,<85"] |=== -| Command | Description -| [source, cypher, role=noplay] +| Command +m| +GRANT ACCESS+ + +| Syntax +a| +[source, syntax, role="noheader", indent=0] +---- GRANT ACCESS - ON {HOME DATABASE \| DATABASE[S] {* \| name[, ...]}} - TO role[, ...] -| Grants the specified roles the privilege to access: + ON { HOME DATABASE \| DATABASE[S] { * \| name[, ...] } } + TO role[, ...] +---- -* the home database -* specific database(s) or remote database alias(es) -* all databases and remote database aliases +| Description +a| +Grants the specified roles the privilege to access: -| [source, cypher, role=noplay] -GRANT {START \| STOP} - ON {HOME DATABASE \| DATABASE[S] {* \| name[, ...]}} - TO role[, ...] -| Grants the specified roles the privilege to start and stop the home database, specific database(s), or all databases. +* The home database. +* Specific database(s) or remote database alias(es). +* All databases and remote database aliases. -| [source, cypher, role=noplay] -GRANT {CREATE \| DROP \| SHOW} INDEX[ES] - ON {HOME DATABASE \| DATABASE[S] {* \| name[, ...]}} - TO role[, ...] +|=== + + +.Database privilege syntax +[cols="<15s,<85"] +|=== + +| Command +m| +GRANT { START \| STOP }+ + +| Syntax +a| +[source, syntax, role="noheader", indent=0] +---- +GRANT { START \| STOP } + ON { HOME DATABASE \| DATABASE[S] {* \| name[, ...] } } + TO role[, ...] +---- + +| Description +| Grants the specified roles the privilege to start or stop the home database, specific database(s), or all databases. + +|=== + + +.Database privilege syntax +[cols="<15s,<85"] +|=== + +| Command +m| +GRANT { CREATE \| DROP \| SHOW } INDEX+ + +| Syntax +a| +[source, syntax, role="noheader", indent=0] +---- +GRANT { CREATE \| DROP \| SHOW } INDEX[ES] + ON { HOME DATABASE \| DATABASE[S] { * \| name[, ...] } } + TO role[, ...] +---- + +| Description | Grants the specified roles the privilege to create, delete, or show indexes on the home database, specific database(s), or all databases. -| [source, cypher, role=noplay] +|=== + + +.Database privilege syntax +[cols="<15s,<85"] +|=== + +| Command +m| +GRANT INDEX+ + +| Syntax +a| +[source, syntax, role="noheader", indent=0] +---- GRANT INDEX[ES] [MANAGEMENT] - ON {HOME DATABASE \| DATABASE[S] {* \| name[, ...]}} - TO role[, ...] + ON { HOME DATABASE \| DATABASE[S] { * \| name[, ...] } } + TO role[, ...] +---- + +| Description | Grants the specified roles the privilege to manage indexes on the home database, specific database(s), or all databases. -| [source, cypher, role=noplay] -GRANT {CREATE \| DROP \| SHOW} CONSTRAINT[S] - ON {HOME DATABASE \| DATABASE[S] {* \| name[, ...]}} - TO role[, ...] +|=== + + +.Database privilege syntax +[cols="<15s,<85"] +|=== + +| Command +m| +GRANT { CREATE \| DROP \| SHOW } CONSTRAINT+ + +| Syntax +a| +[source, syntax, role="noheader", indent=0] +---- +GRANT { CREATE \| DROP \| SHOW } CONSTRAINT[S] + ON { HOME DATABASE \| DATABASE[S] { * \| name[, ...] } } + TO role[, ...] +---- + +| Description | Grants the specified roles the privilege to create, delete, or show constraints on the home database, specific database(s), or all databases. -| [source, cypher, role=noplay] +|=== + + +.Database privilege syntax +[cols="<15s,<85"] +|=== + +| Command +m| +GRANT CONSTRAINT+ + +| Syntax +a| +[source, syntax, role="noheader", indent=0] +---- GRANT CONSTRAINT[S] [MANAGEMENT] - ON {HOME DATABASE \| DATABASE[S] {* \| name[, ...]}} - TO role[, ...] + ON { HOME DATABASE \| DATABASE[S] { * \| name[, ...] } } + TO role[, ...] +---- + +| Description | Grants the specified roles the privilege to manage constraints on the home database, specific database(s), or all databases. -| [source, cypher, role=noplay] +|=== + + +.Database privilege syntax +[cols="<15s,<85"] +|=== + +| Command +m| +GRANT CREATE NEW LABEL+ + +| Syntax +a| +[source, syntax, role="noheader", indent=0] +---- GRANT CREATE NEW [NODE] LABEL[S] - ON {HOME DATABASE \| DATABASE[S] {* \| name[, ...]}} - TO role[, ...] + ON { HOME DATABASE \| DATABASE[S] { * \| name[, ...] } } + TO role[, ...] +---- + +| Description | Grants the specified roles the privilege to create new node labels in the home database, specific database(s), or all databases. -| [source, cypher, role=noplay] +|=== + + +.Database privilege syntax +[cols="<15s,<85"] +|=== + +| Command +m| +GRANT CREATE NEW TYPE+ + +| Syntax +a| +[source, syntax, role="noheader", indent=0] +---- GRANT CREATE NEW [RELATIONSHIP] TYPE[S] - ON {HOME DATABASE \| DATABASE[S] {* \| name[, ...]}} - TO role[, ...] -| Grants the specified roles the privilege to create new relationships types in the home database, specific database(s), or all databases. + ON { HOME DATABASE \| DATABASE[S] { * \| name[, ...] } } + TO role[, ...] +---- + +| Description +| Grants the specified roles the privilege to create new relationship types in the home database, specific database(s), or all databases. + +|=== + + +.Database privilege syntax +[cols="<15s,<85"] +|=== + +| Command +m| +GRANT CREATE NEW NAME+ -| [source, cypher, role=noplay] +| Syntax +a| +[source, syntax, role="noheader", indent=0] +---- GRANT CREATE NEW [PROPERTY] NAME[S] - ON {HOME DATABASE \| DATABASE[S] {* \| name[, ...]}} - TO role[, ...] + ON { HOME DATABASE \| DATABASE[S] { * \| name[, ...] } } + TO role[, ...] +---- + +| Description | Grants the specified roles the privilege to create new property names in the home database, specific database(s), or all databases. -| [source, cypher, role=noplay] +|=== + + +.Database privilege syntax +[cols="<15s,<85"] +|=== + +| Command +m| +GRANT NAME+ + +| Syntax +a| +[source, syntax, role="noheader", indent=0] +---- GRANT NAME [MANAGEMENT] - ON {HOME DATABASE \| DATABASE[S] {* \| name[, ...]}} - TO role[, ...] + ON { HOME DATABASE \| DATABASE[S] { * \| name[, ...] } } + TO role[, ...] +---- + +| Description | Grants the specified roles the privilege to manage new labels, relationship types, and property names in the home database, specific database(s), or all databases. -| [source, cypher, role=noplay] +|=== + + +.Database privilege syntax +[cols="<15s,<85"] +|=== + +| Command +m| +GRANT ALL+ + +| Syntax +a| +[source, syntax, role="noheader", indent=0] +---- GRANT ALL [[DATABASE] PRIVILEGES] - ON {HOME DATABASE \| DATABASE[S] {* \| name[, ...]}} - TO role[, ...] + ON { HOME DATABASE \| DATABASE[S] { * \| name[, ...] } } + TO role[, ...] +---- + +| Description | Grants the specified roles all privileges for the home, a specific, or all databases and remote database aliases. -| [source, cypher, role=noplay] -GRANT {SHOW \| TERMINATE} TRANSACTION[S] [( {* \| user[, ...]} )] -ON {HOME DATABASE \| DATABASE[S] {* \| name[, ...]}} -TO role[, ...] +|=== + + +.Database privilege syntax +[cols="<15s,<85"] +|=== + +| Command +m| +GRANT { SHOW \| TERMINATE } TRANSACTION+ + +| Syntax +a| +[source, syntax, role="noheader", indent=0] +---- +GRANT { SHOW \| TERMINATE } TRANSACTION[S] [( { * \| user[, ...] } )] + ON { HOME DATABASE \| DATABASE[S] { * \| name[, ...] } } + TO role[, ...] +---- + +| Description | Grants the specified roles the privilege to list and end the transactions and queries of all users or a particular user(s) in the home database, specific database(s), or all databases. -| [source, cypher, role=noplay] -GRANT TRANSACTION [MANAGEMENT] [( {* \| user[, ...]} )] -ON {HOME DATABASE \| DATABASE[S] {* \| name[, ...]}} -TO role[, ...] +|=== + + +.Database privilege syntax +[cols="<15s,<85"] +|=== + +| Command +m| +GRANT TRANSACTION+ + +| Syntax +a| +[source, syntax, role="noheader", indent=0] +---- +GRANT TRANSACTION [MANAGEMENT] [( { * \| user[, ...] } )] + ON { HOME DATABASE \| DATABASE[S] { * \| name[, ...] } } + TO role[, ...] +---- + +| Description | Grants the specified roles the privilege to manage the transactions and queries of all users or a particular user(s) in the home database, specific database(s), or all databases. |=== -image::grant-privileges-database.png[title="Syntax of GRANT and DENY Database Privileges"] + +image::privileges_grant_and_deny_syntax_database_privileges.png[title="Syntax of GRANT and DENY Database Privileges"] [[access-control-database-administration-access]] @@ -188,11 +470,11 @@ image::grant-privileges-database.png[title="Syntax of GRANT and DENY Database Pr The `ACCESS` privilege enables users to connect to a database or a remote database alias. With `ACCESS` you can run calculations, for example, `RETURN 2*5 AS answer` or call functions `RETURN timestamp() AS time`. -[source, cypher, role=noplay] +[source, syntax, role="noheader"] ---- GRANT ACCESS - ON {HOME DATABASE | DATABASE[S] {* | name[, ...]}} - TO role[, ...] + ON { HOME DATABASE | DATABASE[S] { * | name[, ...] } } + TO role[, ...] ---- For example, to grant the role `regularUsers` the ability to access the database `neo4j`, use: @@ -204,7 +486,7 @@ GRANT ACCESS ON DATABASE neo4j TO regularUsers The `ACCESS` privilege can also be denied: -[source, cypher, role=noplay] +[source, syntax, role="noheader"] ---- DENY ACCESS ON {HOME DATABASE | DATABASE[S] {* | name[, ...]}} @@ -240,11 +522,11 @@ a|Rows: 2 The `START` privilege can be used to enable the ability to start a database: -[source, cypher, role=noplay] +[source, syntax, role="noheader"] ---- GRANT START - ON {HOME DATABASE | DATABASE[S] {* | name[, ...]}} - TO role[, ...] + ON { HOME DATABASE | DATABASE[S] { * | name[, ...] } } + TO role[, ...] ---- For example, to grant the role `regularUsers` the ability to start the database `neo4j`, use: @@ -256,11 +538,11 @@ GRANT START ON DATABASE neo4j TO regularUsers The `START` privilege can also be denied: -[source, cypher, role=noplay] +[source, syntax, role="noheader"] ---- DENY START - ON {HOME DATABASE | DATABASE[S] {* | name[, ...]}} - TO role[, ...] +ON { HOME DATABASE | DATABASE[S] { * | name[, ...] } } + TO role[, ...] ---- For example, to deny the role `regularUsers` the ability to start to the database `neo4j`, use: @@ -272,11 +554,11 @@ DENY START ON DATABASE system TO regularUsers The `STOP` privilege can be used to enable the ability to stop a database: -[source, cypher, role=noplay] +[source, syntax, role="noheader"] ---- GRANT STOP - ON {HOME DATABASE | DATABASE[S] {* | name[, ...]}} - TO role[, ...] + ON { HOME DATABASE | DATABASE[S] { * | name[, ...] } } + TO role[, ...] ---- For example, to grant the role `regularUsers` the ability to stop the database `neo4j`, use: @@ -288,11 +570,11 @@ GRANT STOP ON DATABASE neo4j TO regularUsers The `STOP` privilege can also be denied: -[source, cypher, role=noplay] +[source, syntax, role="noheader"] ---- DENY STOP - ON {HOME DATABASE | DATABASE[S] {* | name[, ...]}} - TO role[, ...] + ON { HOME DATABASE | DATABASE[S] { * | name[, ...] } } + TO role[, ...] ---- For example, to deny the role `regularUsers` the ability to stop the database `neo4j`, use: @@ -324,7 +606,7 @@ a|Rows: 6 [NOTE] ==== -Note that `START` and `STOP` privileges are not included in the <>. +Note that `START` and `STOP` privileges are not included in the xref::access-control/database-administration.adoc#access-control-database-administration-all[`ALL DATABASE PRIVILEGES`]. ==== @@ -335,25 +617,54 @@ Indexes can be created, deleted, or listed with the `CREATE INDEX`, `DROP INDEX` 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. -.Index management command syntax -[options="header", width="100%", cols="3a,2"] + + + +.Index management privilege syntax +[cols="<15s,<85"] |=== + | Command -| Description +m| +GRANT { CREATE \| DROP \| SHOW } INDEX+ -| [source, cypher, role=noplay] -GRANT {CREATE \| DROP \| SHOW} INDEX[ES] - ON {HOME DATABASE \| DATABASE[S] {* \| name[, ...]}} - TO role[, ...] +| Syntax +a| +[source, syntax, role="noheader", indent=0] +---- +GRANT { CREATE \| DROP \| SHOW } INDEX[ES] + ON { HOME DATABASE \| DATABASE[S] { * \| name[, ...] } } + TO role[, ...] +---- + +| Description | Enables the specified roles to create, delete, or show indexes in the home database, specific database(s), or all databases. -| [source, cypher, role=noplay] +|=== + + + +.Index management privilege syntax +[cols="<15s,<85"] +|=== + +| Command +m| +GRANT INDEX+ + +| Syntax +a| +[source, syntax, role="noheader", indent=0] +---- GRANT INDEX[ES] [MANAGEMENT] - ON {HOME DATABASE \| DATABASE[S] {* \| name[, ...]}} - TO role[, ...] + ON { HOME DATABASE \| DATABASE[S] { * \| name[, ...] } } + TO role[, ...] +---- + +| Description | Enables the specified roles to manage indexes in the home database, specific database(s), or all databases. + |=== + For example, to grant the role `regularUsers` the ability to create indexes on the database `neo4j`, use: [source, cypher, role=noplay] @@ -361,7 +672,7 @@ For example, to grant the role `regularUsers` the ability to create indexes on t GRANT CREATE INDEX ON DATABASE neo4j TO regularUsers ---- -The `SHOW INDEXES` privilege only affects the <>, and not the older procedures for listing indexes, such as `db.indexes`. +The `SHOW INDEXES` privilege only affects the xref::indexes-for-search-performance.adoc#administration-indexes-list-indexes[`SHOW INDEXES` command], and not the older procedures for listing indexes, such as `db.indexes`. [[access-control-database-administration-constraints]] @@ -371,25 +682,51 @@ Constraints can be created, deleted, or listed with the `CREATE CONSTRAINT`, `DR 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. -.Constraint management command syntax -[options="header", width="100%", cols="3a,2"] + +.Constraint management privilege syntax +[cols="<15s,<85"] |=== + | Command -| Description +m| +GRANT { CREATE \| DROP \| SHOW } CONSTRAINT+ -| [source, cypher, role=noplay] -GRANT {CREATE \| DROP \| SHOW} CONSTRAINT[S] - ON {HOME DATABASE \| DATABASE[S] {* \| name[, ...]}} - TO role[, ...] +| Syntax +a| +[source, syntax, role="noheader", indent=0] +---- +GRANT { CREATE \| DROP \| SHOW } CONSTRAINT[S] + ON { HOME DATABASE \| DATABASE[S] { * \| name[, ...] } } + TO role[, ...] +---- + +| Description | Enables the specified roles to create, delete, or show constraints on the home database, specific database(s), or all databases. -| [source, cypher, role=noplay] +|=== + + +.Constraint management privilege syntax +[cols="<15s,<85"] +|=== + +| Command +m| +GRANT CONSTRAINT+ + +| Syntax +a| +[source, syntax, role="noheader", indent=0] +---- GRANT CONSTRAINT[S] [MANAGEMENT] - ON {HOME DATABASE \| DATABASE[S] {* \| name[, ...]}} - TO role[, ...] -| Enables the specified roles to manage constraints on the home database, specific database(s), or all databases. + ON { HOME DATABASE \| DATABASE[S] { * \| name[, ...] } } + TO role[, ...] +---- + +| Description +| Enable the specified roles to manage constraints on the home database, specific database(s), or all databases. + |=== + For example, to grant the role `regularUsers` the ability to create constraints on the database `neo4j`, use: [source, cypher, role=noplay] @@ -397,46 +734,104 @@ For example, to grant the role `regularUsers` the ability to create constraints GRANT CREATE CONSTRAINT ON DATABASE neo4j TO regularUsers ---- -The `SHOW CONSTRAINTS` privilege only affects the <>, and not the older procedures for listing constraints, such as `db.constraints`. +The `SHOW CONSTRAINTS` privilege only affects the xref::constraints/syntax.adoc#administration-constraints-syntax-list[`SHOW CONSTRAINTS` command], and not the older procedures for listing constraints, such as `db.constraints`. [[access-control-database-administration-tokens]] == 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. +The latter is managed using database `WRITE` privileges, while the former is managed using specific `+GRANT/DENY CREATE NEW ...+` commands for each type. -.Label, relationship type and property name management command syntax -[options="header", width="100%", cols="3a,2"] + +.Node label management privileges syntax +[cols="<15s,<85"] |=== + | Command -| Description +m| +GRANT CREATE NEW LABEL+ -| [source, cypher, role=noplay] +| Syntax +a| +[source, syntax, role="noheader", indent=0] +---- GRANT CREATE NEW [NODE] LABEL[S] - ON {HOME DATABASE \| DATABASE[S] {* \| name[, ...]}} - TO role[, ...] + ON { HOME DATABASE \| DATABASE[S] { * \| name[, ...] } } + TO role[, ...] +---- + +| Description | Enables the specified roles to create new node labels in the home database, specific database(s), or all databases. -| [source, cypher, role=noplay] +|=== + + +.Relationship type management privileges syntax +[cols="<15s,<85"] +|=== + +| Command +m| +GRANT CREATE NEW TYPE+ + +| Syntax +a| +[source, syntax, role="noheader", indent=0] +---- GRANT CREATE NEW [RELATIONSHIP] TYPE[S] - ON {HOME DATABASE \| DATABASE[S] {* \| name[, ...]}} - TO role[, ...] + ON { HOME DATABASE \| DATABASE[S] { * \| name[, ...] } } + TO role[, ...] +---- + +| Description | Enables the specified roles to create new relationship types in the home database, specific database(s), or all databases. -| [source, cypher, role=noplay] +|=== + + +.Property name management privileges syntax +[cols="<15s,<85"] +|=== + +| Command +m| +GRANT CREATE NEW NAME+ + +| Syntax +a| +[source, syntax, role="noheader", indent=0] +---- GRANT CREATE NEW [PROPERTY] NAME[S] - ON {HOME DATABASE \| DATABASE[S] {* \| name[, ...]}} - TO role[, ...] + ON { HOME DATABASE \| DATABASE[S] { * \| name[, ...] } } + TO role[, ...] +---- + +| Description | Enables the specified roles to create new property names in the home database, specific database(s), or all databases. -| [source, cypher, role=noplay] +|=== + + +.Node label, relationship type, and property name privileges management syntax +[cols="<15s,<85"] +|=== + +| Command +m| +GRANT NAME+ + +| Syntax +a| +[source, syntax, role="noheader", indent=0] +---- GRANT NAME [MANAGEMENT] - ON {HOME DATABASE \| DATABASE[S] {* \| name[, ...]}} - TO role[, ...] + ON { HOME DATABASE \| DATABASE[S] { * \| name[, ...] } } + TO role[, ...] +---- + +| Description | Enables the specified roles to create new labels, relationship types, and property names in the home database, specific database(s), or all databases. + |=== + For example, to grant the role `regularUsers` the ability to create new properties on nodes or relationships on the database `neo4j`, use: [source, cypher, role=noplay] @@ -450,7 +845,7 @@ GRANT CREATE NEW PROPERTY NAME ON DATABASE neo4j TO regularUsers 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: -[source, cypher, role=noplay] +[source, syntax, role="noheader"] ---- GRANT ALL [[DATABASE] PRIVILEGES] ON {HOME DATABASE | DATABASE[S] {* | name[, ...]}} @@ -491,34 +886,76 @@ a|Rows: 1 The right to run the commands `SHOW TRANSACTIONS`, `TERMINATE TRANSACTIONS`, and the deprecated procedures `dbms.listTransactions`, `dbms.listQueries`, `dbms.killQuery`, `dbms.killQueries`, `dbms.killTransaction` and `dbms.killTransactions` is now managed through the `SHOW TRANSACTION` and `TERMINATE TRANSACTION` privileges. -.Transaction management command syntax -[options="header", width="100%", cols="3a,2"] + +.Database privilege syntax +[cols="<15s,<85"] |=== + | Command -| Description +m| +GRANT SHOW TRANSACTION+ -| [source, cypher, role=noplay] -GRANT SHOW TRANSACTION[S] [( {* \| user[, ...]} )] - ON {HOME DATABASE \| DATABASE[S] {* \| name[, ...]}} - TO role[, ...] +| Syntax +a| +[source, syntax, role="noheader", indent=0] +---- +GRANT SHOW TRANSACTION[S] [( { * \| user[, ...] } )] + ON { HOME DATABASE \| DATABASE[S] { * \| name[, ...] } } + TO role[, ...] +---- + +| Description | Enables the specified roles to list transactions and queries for user(s) or all users in the home database, specific database(s), or all databases. -| [source, cypher, role=noplay] -GRANT TERMINATE TRANSACTION[S] [( {* \| user[, ...]} )] - ON {HOME DATABASE \| DATABASE[S] {* \| name[, ...]}} - TO role[, ...] +|=== + + +.Database privilege syntax +[cols="<15s,<85"] +|=== + +| Command +m| +GRANT TERMINATE TRANSACTION+ + +| Syntax +a| +[source, syntax, role="noheader", indent=0] +---- +GRANT TERMINATE TRANSACTION[S] [( { * \| user[, ...] } )] + ON { HOME DATABASE \| DATABASE[S] { * \| name[, ...] } } + TO role[, ...] +---- + +| Description | Enables the specified roles to end running transactions and queries for user(s) or all users in the home database, specific database(s), or all databases. -| [source, cypher, role=noplay] -GRANT TRANSACTION [MANAGEMENT] [( {* \| user[, ...]} )] - ON {HOME DATABASE \| DATABASE[S] {* \| name[, ...]}} - TO role[, ...] +|=== + + +.Database privilege syntax +[cols="<15s,<85"] +|=== + +| Command +m| +GRANT TRANSACTION+ + +| Syntax +a| +[source, syntax, role="noheader", indent=0] +---- +GRANT TRANSACTION [MANAGEMENT] [( { * \| user[, ...] } )] + ON { HOME DATABASE \| DATABASE[S] { * \| name[, ...] } } + TO role[, ...] +---- + +| Description | Enables the specified roles to manage transactions and queries for user(s) or all users in the home database, specific database(s), or all databases. + |=== + [NOTE] ==== -Note that the `TRANSACTION MANAGEMENT` privileges are not included in the <>. +Note that the `TRANSACTION MANAGEMENT` privileges are not included in the xref::access-control/database-administration.adoc#access-control-database-administration-all[`ALL DATABASE PRIVILEGES`]. ==== For example, to grant the role `regularUsers` the ability to list transactions for user `jake` on the database `neo4j`, use: From ce257b9b14791a2c8cfea9ea4a90a13b8525b32b Mon Sep 17 00:00:00 2001 From: lidiazuin <102308961+lidiazuin@users.noreply.github.com> Date: Tue, 26 Jul 2022 12:12:04 +0200 Subject: [PATCH 4/5] fixing commands list components of the database privilege commands --- modules/ROOT/pages/access-control/database-administration.adoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/modules/ROOT/pages/access-control/database-administration.adoc b/modules/ROOT/pages/access-control/database-administration.adoc index 9dae88475..223098c35 100644 --- a/modules/ROOT/pages/access-control/database-administration.adoc +++ b/modules/ROOT/pages/access-control/database-administration.adoc @@ -12,7 +12,7 @@ This section explains how to use Cypher to manage Neo4j database administrative Administrators can use the following Cypher commands to manage Neo4j database administrative rights. The components of the database privilege commands are: -* the commands: +* _commands_: ** `GRANT` – gives privileges to roles. ** `DENY` – denies privileges to roles. ** `REVOKE` – removes granted or denied privileges from roles. From 2540f0fce224f02757a905957310efa27f1b979e Mon Sep 17 00:00:00 2001 From: lidiazuin <102308961+lidiazuin@users.noreply.github.com> Date: Tue, 26 Jul 2022 12:13:04 +0200 Subject: [PATCH 5/5] Update modules/ROOT/pages/access-control/database-administration.adoc Co-authored-by: Martin --- modules/ROOT/pages/access-control/database-administration.adoc | 1 + 1 file changed, 1 insertion(+) diff --git a/modules/ROOT/pages/access-control/database-administration.adoc b/modules/ROOT/pages/access-control/database-administration.adoc index 223098c35..78fc17b71 100644 --- a/modules/ROOT/pages/access-control/database-administration.adoc +++ b/modules/ROOT/pages/access-control/database-administration.adoc @@ -10,6 +10,7 @@ This section explains how to use Cypher to manage Neo4j database administrative -- Administrators can use the following Cypher commands to manage Neo4j database administrative rights. + The components of the database privilege commands are: * _commands_: