Permission and Ownership – Linux Foundation for DevOps

Practical Usage (Local Environment)

How this is practiced today:

• Create files and change their permissions
• Block and allow execution of scripts
• Change file ownership between users
• Use sudo to fix protected files
• Reproduce and fix permission denied errors

Everything is done on a local Linux machine or VM.

Demo

Orientation — rwx, users, groups, others

In this demo, I demonstrate:

1. Ownership (user, group, others) & their Permission (rwx)
2. To check permission of current directory using ls -l.
3. Understand file-type using file and permission on:
   • owner
   • group
   • other

Numeric modes

In this demo, I demonstrate:

1. Explain numeric values like
   • 7 means rwx
   • 6 means rw-
   • 5 means r-x
   • 4 means r--
   • 3 means -wx
   • 2 means -w-
   • 1 means --x
2. Show Numeric modes along with permission in human readable-form using stat

Break & fix access – chmod

In this demo, I demonstrate:

1. Create a script file, using nano add input and try to execute it.
2. Create a directory named break, remove x permission and see changes.

Ownership — chown

In this demo, I demonstrate:

1. Change owner to root of script file.
2. Explain what happend when executing file and why it worked.

Groups — chgrp

In this demo, I demonstrate:

1. Change group to root of script file.
2. Explain what happend when executing file and why it NOT worked.

sudo basic

In this demo, I demonstrate:

1. read, write, execute operation using sudo.
2. Explain what happend.

Operational Confidence (Current State)

After completing these demos, I am confident that I can:

• Interpret permission strings like -rwxr-xr-- to know exactly who can do what
• Predict what will happen before running a file based on its mode
• Use chmod to break and restore execution intentionally
• Change ownership with chown and understand how it affects execution
• Use chgrp to restrict or allow access via group membership
• Use sudo to override permissions when necessary without guessing

DevOps Scenarios Where This Applies (Forward-Looking)

These exact behaviors map directly to real DevOps failures such as:

• CI/CD pipelines failing because build scripts lack +x
• Docker containers crashing because mounted volumes belong to root
• Web servers returning 403 because config files have wrong group ownership
• SSH refusing to use keys because permissions are too open
• Cloud VM setup scripts failing because ownership was changed accidentally

Notes & Observations

Based on what I saw during the demos:

• Permission denied almost always means wrong owner or missing x
• A file with r but no x can be read but never executed
• Changing owner to root can silently block or allow execution
• Group ownership matters only when group permissions allow it
• sudo does not change file permissions — it changes who is executing

Status & Next Step

Current status: ⏳ Active
Next work card: Users & Groups

Small, validated progress beats broad, unverified knowledge.