Instead of creating new roles from scratch, we can use the built-in roles as a template, when all we need is the equivalent of a built-in role scoped down to a specific database or databases.

We do this by creating a new role as a copy of an existing role. Then we can revoke global database access, then grant access to the database or databases that the role should have access to.

So to create the equivalent of the reader role but to database db1, and grant it to user_a, we would do the following from the system database:

Of course, user_a and database db1 must exist first for this to be successful.

This grants privileges equivalent to the reader role, but constraints the user’s access to only database db1.

It’s important to note that the db1_reader role doesn’t actually have reader privileges scoped to only db1. They still have full read privileges across any and all databases (as copied from the built-in reader role), it’s just that currently, their role only allows access on db1. We had only revoked the ACCESS from all database, not the READ privilege.

If the user was granted another role that granted access privileges on a different database and didn’t constrain their privileges in some way, then the global read privileges inherent in the db1_reader role would allow them to be a reader of the new database.

Let’s illustrate that by adding a new role db2_accessor, and granting it to user_a:

Even though the db2_accessor role merely gives access to the database, no permissions for reading, writing, or anything else, because of the global read privileges from db1_reader, user_a can read everything on db2.

Let’s check user_a’s privileges to verify:

The ability for privileges to combine isn’t necessarily an obstacle. Sometimes it can be very useful.

For example, what if we’re fine with having this combined read access, but we want to make sure no matter what database we’re using, that this user can’t read or match to SSN properties on :Person nodes. We can add a special role just for this restriction.

If we wanted the tightest level of security, scoping privileges such that granting of a new role (and access of a new database) won’t give unintentionally wide privileges, then we need to abandon the idea of copying the built-in roles when creating new ones. Their privileges are database-wide, which may be too permissive for what we want.

Instead, we need to grant the privileges manually and scope them to the database or databases in question.

Let’s drop the db1_reader role and recreate it with more narrowly scoped privileges:

The https://neo4j.com/docs/cypher-manual/current/access-control/manage-privileges/#access-control-graph-privileges[MATCH privilege] is shorthand for both READ and TRAVERSE privileges, so this saves us a line.

Now let’s check user_a’s privileges again:

We can see that although user_a has access to both db1 and db2 databases, the read and traverse privileges we granted to db1_reader are scoped just to db1. User_a can access db2, but can’t actually do anything there until we grant them more privileges on one of their existing roles, or via a new role.