Built-in roles and privileges

This section explains the default privileges of the built-in roles in Neo4j and how to recreate them if needed.

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:

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

1.1. Listing PUBLIC role privileges

SHOW ROLE PUBLIC PRIVILEGES AS COMMANDS
Table 1. Result
command

"GRANT ACCESS ON HOME DATABASE TO `PUBLIC`"

"GRANT EXECUTE FUNCTION * ON DBMS TO `PUBLIC`"

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

Rows: 3

1.2. Recreating the PUBLIC role

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:

GRANT ACCESS ON HOME DATABASE TO PUBLIC
GRANT EXECUTE PROCEDURES * ON DBMS TO PUBLIC
GRANT EXECUTE USER DEFINED FUNCTIONS * ON DBMS TO PUBLIC

The resulting PUBLIC role now has the same privileges as the original built-in PUBLIC role.

2. The reader role

The reader role can perform read-only queries on all graphs except for the system database.

2.1. Listing reader role privileges

SHOW ROLE reader PRIVILEGES AS COMMANDS
Table 2. Result
command

"GRANT ACCESS ON DATABASE * TO `reader`"

"GRANT MATCH {*} ON GRAPH * NODE * TO `reader`"

"GRANT MATCH {*} ON GRAPH * RELATIONSHIP * TO `reader`"

Rows: 3

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

CREATE ROLE reader
GRANT ACCESS ON DATABASE * TO reader
GRANT MATCH {*} ON GRAPH * TO reader

The resulting reader role now has the same privileges as the original built-in reader role.

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

3.1. Listing editor role privileges

SHOW ROLE editor PRIVILEGES AS COMMANDS
Table 3. Result
command

"GRANT ACCESS ON DATABASE * TO `editor`"

"GRANT MATCH {*} ON GRAPH * NODE * TO `editor`"

"GRANT MATCH {*} ON GRAPH * RELATIONSHIP * TO `editor`"

"GRANT WRITE ON GRAPH * TO `editor`"

Rows: 4

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

CREATE ROLE editor
GRANT ACCESS ON DATABASE * TO editor
GRANT MATCH {*} ON GRAPH * TO editor
GRANT WRITE ON GRAPH * TO editor

The resulting editor role now has the same privileges as the original built-in editor role.

4. The publisher role

The publisher role can do the same as editor, but can also create new labels, property keys and relationship types.

4.1. Listing publisher role privileges

SHOW ROLE publisher PRIVILEGES AS COMMANDS
Table 4. Result
command

"GRANT ACCESS ON DATABASE * TO `publisher`"

"GRANT MATCH {*} ON GRAPH * NODE * TO `publisher`"

"GRANT MATCH {*} ON GRAPH * RELATIONSHIP * TO `publisher`"

"GRANT NAME MANAGEMENT ON DATABASE * TO `publisher`"

"GRANT WRITE ON GRAPH * TO `publisher`"

Rows: 5

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

CREATE ROLE publisher
GRANT ACCESS ON DATABASE * TO publisher
GRANT MATCH {*} ON GRAPH * TO publisher
GRANT WRITE ON GRAPH * TO publisher
GRANT NAME MANAGEMENT ON DATABASE * TO publisher

The resulting publisher role now has the same privileges as the original built-in publisher role.

5. The architect role

The architect role can do the same as the publisher, as well as create and manage indexes and constraints.

5.1. Listing architect role privileges

SHOW ROLE architect PRIVILEGES AS COMMANDS
Table 5. Result
command

"GRANT ACCESS ON DATABASE * TO `architect`"

"GRANT CONSTRAINT MANAGEMENT ON DATABASE * TO `architect`"

"GRANT INDEX MANAGEMENT ON DATABASE * TO `architect`"

"GRANT MATCH {*} ON GRAPH * NODE * TO `architect`"

"GRANT MATCH {*} ON GRAPH * RELATIONSHIP * TO `architect`"

"GRANT NAME MANAGEMENT ON DATABASE * TO `architect`"

"GRANT WRITE ON GRAPH * TO `architect`"

Rows: 7

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

GRANT ACCESS ON DATABASE * TO architect
GRANT MATCH {*} ON GRAPH * TO architect
GRANT WRITE ON GRAPH * TO architect
GRANT NAME MANAGEMENT ON DATABASE * TO architect
GRANT INDEX MANAGEMENT ON DATABASE * TO architect
GRANT CONSTRAINT MANAGEMENT ON DATABASE * TO architect

The resulting architect role now has the same privileges as the original built-in architect role.

6. The admin role

The admin role can do the same as the architect, as well as manage databases, 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 database security for controlling the rights to perform actions on specific databases:

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

    • Manage indexes and constraints

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

    • Manage transactions

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

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

6.1. Listing admin role privileges

SHOW ROLE admin PRIVILEGES AS COMMANDS
Table 6. Result
command

"GRANT ACCESS ON DATABASE * TO `admin`"

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

"GRANT CONSTRAINT MANAGEMENT ON DATABASE * TO `admin`"

"GRANT INDEX MANAGEMENT ON DATABASE * TO `admin`"

"GRANT MATCH {*} ON GRAPH * NODE * TO `admin`"

"GRANT MATCH {*} ON GRAPH * RELATIONSHIP * TO `admin`"

"GRANT NAME MANAGEMENT ON DATABASE * TO `admin`"

"GRANT START ON DATABASE * TO `admin`"

"GRANT STOP ON DATABASE * TO `admin`"

"GRANT TRANSACTION MANAGEMENT (*) ON DATABASE * TO `admin`"

"GRANT WRITE ON GRAPH * TO `admin`"

Rows: 11

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

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

CREATE ROLE admin
GRANT ALL DBMS PRIVILEGES ON DBMS TO admin
GRANT TRANSACTION MANAGEMENT ON DATABASE * TO admin
GRANT START ON DATABASE * TO admin
GRANT STOP ON DATABASE * TO admin
GRANT MATCH {*} ON GRAPH * TO admin
GRANT WRITE ON GRAPH * TO admin
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 Operations Manual → Recover the admin role.