The most detailed free FDE + DevOps library: 140+ lessons, 70+ labs and 80 long-form articles, in English and Turkish. Start learning →

TürkçeSearch

DevOps Foundations · Module 1: Linux working model · Lab

Fix the Service That Permissions Broke

40 min hands-on · Core

Local Linux shell plus any local service or supervisor you already run; all fixture files live under /tmp/dlab-m01-01.

Run this lab on Killercoda →

Two ways to do this lab: in your browser on Killercoda (free, no install), or on your own machine as a local guide. Killercoda runs one free scenario at a time: if you see a waiting queue, close other Killercoda tabs and wait a minute.

Objectives

  • Reproduce a permission-denied service failure from the service user's side
  • Name the process user and the file owner before changing anything
  • Repair with the narrowest mode that works and prove it as the service user

  1. Step 1

    Build the broken scene

    Create /tmp/dlab-m01-01 with a config file owned by you at mode 600, then simulate the service user by checking the file with 'sudo -u nobody head' where available, or by reasoning from 'id' and 'ls -l' output where sudo is absent. Record the exact denial line.

  2. Step 2

    Diagnose before repair

    Write down the two users (reader, owner), the applicable permission column, and the two candidate repairs from lesson 1 (chgrp + 640 vs chown + 600). Pick one and write why the other is worse here.

  3. Step 3

    Repair narrowly and verify

    Group path (proves membership first): sudo groupadd appconfig; sudo usermod -aG appconfig $USER; sudo usermod -aG appconfig nobody; newgrp appconfig or re-login so id shows the group; then sudo chgrp appconfig /tmp/dlab-m01-01/config.env && sudo chmod 640 /tmp/dlab-m01-01/config.env. Ownership path instead: sudo chown nobody:nogroup /tmp/dlab-m01-01/config.env && sudo chmod 600. Also check the directory allows traversal (chmod 751 /tmp/dlab-m01-01 if needed). Then verify with the same read command that failed in step 1. Confirm no file in the directory is wider than 640.

How to confirm it worked

  • The initial denial is reproduced and quoted in the record
  • The repair leaves no file wider than 640 (shown with ls -l)
  • Verification repeats the exact failing read and succeeds
  • The record explains the command choices in under 150 words