Access control matrix in Operating Systems - Step-by-Step Execution

Concept Flow - Access control matrix

Start

↓

Define Subjects

↓

Define Objects

↓

Create Matrix

↓

Assign Rights

↓

Check Access Request

↓

Allow or Deny Access

↓

End

The access control matrix starts by defining who (subjects) and what (objects) are involved, then creates a matrix assigning rights, and finally checks access requests to allow or deny actions.

Execution Sample

Operating Systems

Subjects = ['Alice', 'Bob']
Objects = ['File1', 'File2']
Matrix = {
  'Alice': {'File1': ['read', 'write'], 'File2': ['read']},
  'Bob': {'File1': ['read']}
}

This sets up an access control matrix showing which subjects have which rights on which objects.

Analysis Table

Step	Action	Subject	Object	Rights Checked	Access Decision
1	Check if Alice can write File1	Alice	File1	write	Allow
2	Check if Bob can write File1	Bob	File1	write	Deny
3	Check if Alice can read File2	Alice	File2	read	Allow
4	Check if Bob can read File2	Bob	File2	read	Deny
5	Check if Alice can execute File1	Alice	File1	execute	Deny
6	Check if Bob can read File1	Bob	File1	read	Allow
7	End of access checks	-	-	-	-

💡 All access requests checked; decisions made based on rights in the matrix.

State Tracker

Variable	Start	After Step 1	After Step 2	After Step 3	After Step 4	After Step 5	After Step 6	Final
Subjects	['Alice', 'Bob']	['Alice', 'Bob']	['Alice', 'Bob']	['Alice', 'Bob']	['Alice', 'Bob']	['Alice', 'Bob']	['Alice', 'Bob']	['Alice', 'Bob']
Objects	['File1', 'File2']	['File1', 'File2']	['File1', 'File2']	['File1', 'File2']	['File1', 'File2']	['File1', 'File2']	['File1', 'File2']	['File1', 'File2']
Matrix	{'Alice': {'File1': ['read', 'write'], 'File2': ['read']}, 'Bob': {'File1': ['read']}}	{...}	{...}	{...}	{...}	{...}	{...}	{...}
Access Decision	-	Allow	Deny	Allow	Deny	Deny	Allow	Completed

Key Insights - 3 Insights

Why does Bob get denied write access to File1 even though he can read it?

Because the matrix only grants Bob the 'read' right on File1, not 'write'. The execution_table rows 2 and 6 show this difference clearly.

What happens if a subject requests a right not listed in the matrix for an object?

The access is denied, as shown in step 5 where Alice requests 'execute' on File1 but only has 'read' and 'write' rights.

Are the subjects and objects changed during access checks?

No, subjects and objects remain constant throughout the process, as shown in the variable_tracker where their values do not change.

Visual Quiz - 3 Questions

Look at the execution_table at step 4. What is the access decision for Bob reading File2?

A Allow

B Not checked

C Deny

D Error

💡 Hint

Check the 'Access Decision' column in execution_table row 4.

At which step does Alice get denied access for a requested right?

A Step 3

B Step 5

C Step 1

D Step 6

💡 Hint

Look for 'Deny' in the 'Access Decision' column for Alice in execution_table.

If Bob was given 'write' rights on File1 in the matrix, what would change in the execution_table?

A Step 2 would change to Allow

B Step 4 would change to Allow

C Step 6 would change to Deny

D No changes

💡 Hint

Compare step 2 where Bob is denied write access to File1.

Concept Snapshot

Access Control Matrix:
- Rows = Subjects (users/processes)
- Columns = Objects (files/resources)
- Cells = Rights (read, write, execute)
- Check access by looking up subject-object-right
- Allow if right exists, else deny

Full Transcript

An access control matrix is a way to manage who can do what with resources. We list subjects (like Alice and Bob) and objects (like File1 and File2). Then we create a matrix that shows which rights each subject has on each object. When a subject requests access, we check the matrix. If the right is there, access is allowed; if not, it is denied. This process is shown step-by-step in the execution table, with variable states tracked to show no changes to subjects or objects during checks.