Permission and Ownership – Linux Foundation for DevOps

Epic: Linux Foundation for DevOps
Work Card: Permission and Ownership
Parent Hub: Building My DevOps Skills in Public
Trello Card: link
Status: ⏳ Active

Introduction

As someone preparing for a DevOps role, I’m learning Linux with a lean approach — focusing only on what’s required to operate and debug real servers.

This post covers Permission and Ownership and hands-on demonstrations on Youtube, from a DevOps perspective.

---

Objective

This work card focuses on learning how Linux file permissions and ownership work so I can safely operate inside servers, containers, and CI environments without accidentally breaking applications or blocking access.

---

Why This Matters for DevOps

These skills appear everywhere in DevOps:

• Deploying applications on Linux servers
• Running containers that need file access
• Fixing “permission denied” errors in CI/CD
• Securing config files, SSH keys, and scripts

If permissions are wrong, systems fail silently or dangerously.

---

Scope

Included:

• rwx permissions and numeric modes (755, 644)
• chmod, chown, chgrp
• user, group, and others
• sudo basics

Explicitly excluded (for now):

• ACLs
• SELinux / AppArmor
• Advanced Linux security models

---

Minimum Required Concepts

Concept	Purpose
rwx (read, write, execute)	Controls who can open, modify, or run files
user / group / others	Defines who the permission applies to
chmod	Changes file and directory permissions
chown	Changes file owner
chgrp	Changes file group
Numeric modes (755, 644)	Fast way to set permissions in scripts and CI
sudo	Run commands as root safely

---

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.