Role-based access control in MongoDB - Time & Space Complexity

Time Complexity: Role-based access control

O(n)

Understanding Time Complexity

When using role-based access control in MongoDB, we want to know how the time to check permissions changes as the number of roles or users grows.

We ask: How does the system handle more roles or users without slowing down too much?

Scenario Under Consideration

Analyze the time complexity of the following MongoDB role check.

// Check if user has a role
const user = db.users.findOne({ username: "alice" });
const hasRole = user.roles.includes("readWrite");
if (hasRole) {
  // allow action
} else {
  // deny action
}
    

This code finds a user document and checks if the user has a specific role in their roles list.

Identify Repeating Operations

Look for repeated steps that take time as data grows.

• Primary operation: Searching through the user's roles array to find a matching role.
• How many times: The check goes through each role in the array until it finds a match or finishes.

How Execution Grows With Input

As the number of roles a user has increases, the time to check if a role exists grows.

Input Size (n)	Approx. Operations
10 roles	Up to 10 checks
100 roles	Up to 100 checks
1000 roles	Up to 1000 checks

Pattern observation: The time grows roughly in direct proportion to the number of roles checked.

Final Time Complexity

Time Complexity: O(n)

This means the time to check a role grows linearly with the number of roles the user has.

Common Mistake

[X] Wrong: "Checking a role is always instant no matter how many roles a user has."

[OK] Correct: The system must look through the roles list one by one, so more roles mean more time to check.

Interview Connect

Understanding how role checks scale helps you design systems that stay fast as users and roles grow. This skill shows you can think about real-world system performance.

Self-Check

"What if roles were stored in a set or indexed structure instead of a list? How would the time complexity change?"

Practice

1. What is the main purpose of role-based access control (RBAC) in MongoDB?

easy

A. To optimize query performance automatically

B. To store data in a structured format

C. To manage user permissions by assigning roles with specific privileges

D. To backup the database regularly

Solution

1. Step 1: Understand RBAC concept

   RBAC is about controlling what users can do by giving them roles with permissions.

2. Step 2: Identify RBAC purpose in MongoDB

   MongoDB uses RBAC to assign roles that define user privileges, managing access securely.

3. Final Answer:

   To manage user permissions by assigning roles with specific privileges -> Option C

4. Quick Check:

   RBAC controls access by roles = A [OK]

Hint: RBAC controls user actions via roles, not data or backups [OK]

Common Mistakes:

• Confusing RBAC with data storage
• Thinking RBAC handles backups
• Assuming RBAC optimizes queries

2. Which of the following is the correct syntax to create a role named readOnlyUser with read access on the sales database?

easy

A. db.createRole({role: "readOnlyUser", privileges: [{resource: {db: "sales", collection: ""}, actions: ["find"]}], roles: []})

B. db.createRole({name: "readOnlyUser", privileges: [{resource: {db: "sales", collection: ""}, actions: ["find"]}], roles: []})

C. db.createRole({role: "readOnlyUser", privileges: [{resource: {db: "sales"}, actions: ["insert"]}], roles: []})

D. db.createRole({name: "readOnlyUser", privileges: [{resource: {db: "sales", collection: ""}, actions: ["update"]}], roles: []})

Solution

1. Step 1: Check correct field for role name

   The field to name the role is name, not role.

2. Step 2: Verify privileges for read access

   Read access uses the find action on the database with empty collection string for all collections.

3. Final Answer:

   db.createRole({name: "readOnlyUser", privileges: [{resource: {db: "sales", collection: ""}, actions: ["find"]}], roles: []}) -> Option B

4. Quick Check:

   Role name uses 'name' field = A [OK]

Hint: Use 'name' for role, 'find' for read, empty collection for all [OK]

Common Mistakes:

• Using 'role' instead of 'name' for role creation
• Assigning wrong actions like 'insert' for read role
• Missing empty string for collection to cover all

3. Given the following commands, what will be the result of db.runCommand({usersInfo: "alice"}) after assigning the role?

db.createRole({
  name: "reportViewer",
  privileges: [{resource: {db: "reports", collection: ""}, actions: ["find"]}],
  roles: []
})
db.createUser({
  user: "alice",
  pwd: "password123",
  roles: ["reportViewer"]
})

medium

A. Returns user info showing 'alice' has role 'reportViewer' with find privileges on 'reports'

B. Returns an error because 'reportViewer' role does not exist

C. Returns user info but shows no roles assigned to 'alice'

D. Returns user info showing 'alice' has admin role

Solution

1. Step 1: Confirm role creation and assignment

   The role 'reportViewer' is created with find privileges on 'reports' and assigned to user 'alice'.

2. Step 2: Understand usersInfo command output

   Running usersInfo for 'alice' shows user details including assigned roles and privileges.

3. Final Answer:

   Returns user info showing 'alice' has role 'reportViewer' with find privileges on 'reports' -> Option A

4. Quick Check:

   Role assigned correctly, usersInfo shows it = C [OK]

Hint: usersInfo shows assigned roles and privileges correctly [OK]

Common Mistakes:

• Assuming usersInfo errors if role was just created
• Expecting no roles shown after assignment
• Confusing assigned roles with admin role

4. You tried to create a role with this command:

db.createRole({
  role: "dataEditor",
  privileges: [{resource: {db: "inventory", collection: "products"}, actions: ["update"]}],
  roles: []
})

But it failed. What is the error?

medium

A. The field 'role' should be 'name' when creating a role

B. The 'actions' array cannot contain 'update'

C. The 'resource' field must include 'collection' as null, not a string

D. Roles cannot have empty 'roles' array

Solution

1. Step 1: Check role creation syntax

   The correct field to name a role is 'name', not 'role'. Using 'role' causes failure.

2. Step 2: Validate other fields

   Actions like 'update' are valid, collection as string is correct, and empty roles array is allowed.

3. Final Answer:

   The field 'role' should be 'name' when creating a role -> Option A

4. Quick Check:

   Use 'name' field for role creation = B [OK]

Hint: Use 'name' not 'role' to name roles in createRole [OK]

Common Mistakes:

• Using 'role' instead of 'name' for role name
• Thinking 'update' is invalid action
• Believing empty roles array is disallowed

5. You want to create a custom role manager that can read and update documents in the employees database and also inherit all privileges from the built-in read role on the same database. Which command correctly achieves this?

hard

A. db.createRole({name: "manager", privileges: [{resource: {db: "employees", collection: "employees"}, actions: ["find", "update"]}], roles: [{role: "read", db: "employees"}]})

B. db.createRole({name: "manager", privileges: [{resource: {db: "employees", collection: "employees"}, actions: ["find", "update"]}], roles: [{role: "read", db: "admin"}]})

C. db.createRole({name: "manager", privileges: [{resource: {db: "employees", collection: "employees"}, actions: ["insert", "update"]}], roles: [{role: "read", db: "employees"}]})

D. db.createRole({name: "manager", privileges: [{resource: {db: "employees", collection: ""}, actions: ["find", "update"]}], roles: [{role: "read", db: "employees"}]})

Solution

1. Step 1: Check privileges for read and update on employees

   Privileges should apply to all collections in 'employees' database, so collection is empty string "".

2. Step 2: Verify inherited role database

   The built-in 'read' role must be inherited from the same database 'employees', not 'admin'.

3. Step 3: Confirm actions and roles

   Actions 'find' and 'update' are correct; 'insert' is not required here.

4. Final Answer:

   db.createRole({name: "manager", privileges: [{resource: {db: "employees", collection: ""}, actions: ["find", "update"]}], roles: [{role: "read", db: "employees"}]}) -> Option D

5. Quick Check:

   Empty collection for all, inherit 'read' from same DB = D [OK]

Hint: Use empty collection for all, inherit roles from same DB [OK]

Common Mistakes:

• Setting collection name instead of empty string for all
• Inheriting 'read' role from wrong database
• Using wrong actions like 'insert' instead of 'find'