Permission and Ownership – Linux Foundation for DevOps

Source: Dev.to

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 includes hands‑on demonstrations (see the YouTube playlist) from a DevOps perspective.

Objective

Learn how Linux file permissions and ownership work so you 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 pipelines
• 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
• Basic sudo usage

Explicitly excluded (for now)

• ACLs
• SELinux / AppArmor
• Advanced Linux security models

Minimum Required Concepts

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

All activities are performed on a local Linux machine or VM.

Demo

Orientation — rwx, users, groups, others

• Show ownership (user, group, others) and their permissions (rwx).
• Use ls -l to check permissions of the current directory.
• Use file to identify file type and examine permissions for owner, group, and others.

Numeric modes

Explain numeric values:

• 7 → rwx
• 6 → rw-
• 5 → r-x
• 4 → r--
• 3 → -wx
• 2 → -w-
• 1 → --x

Show numeric modes alongside human‑readable permissions using stat.

Break & fix access — chmod

• Create a script file, edit it with nano, add some commands, and attempt to execute it.
• Create a directory named break, remove the execute (x) permission, and observe the effect.

Ownership — chown

• Change the owner of the script file to root.
• Explain what happens when the file is executed and why it works (or doesn’t).

Groups — chgrp

• Change the group of the script file to root.
• Explain why execution may fail when group permissions are insufficient.

sudo basic

• Perform read, write, and execute operations using sudo.
• Explain the outcome and how sudo affects execution without altering file permissions.

Operational Confidence (Current State)

After completing these demos, you should be able to:

• Interpret permission strings like -rwxr-xr-- to know exactly who can do what.
• Predict the behavior of a file before running it based on its mode.
• Use chmod to break and restore execution intentionally.
• Change ownership with chown and understand its impact on 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 behaviors map directly to real DevOps failures such as:

• CI/CD pipelines failing because build scripts lack the +x flag.
• Docker containers crashing because mounted volumes belong to root.
• Web servers returning 403 because config files have the 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

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

Status & Next Step

Current status: ⏳ Active

Next work card: Users & Groups

Small, validated progress beats broad, unverified knowledge.