Skip to content
Linux Administration
Lab 10 of 27·25mChallengeBeginner

Day 05 challenge: the locked-out team

Two users cannot use a shared directory that looks correctly configured. Four things are wrong. Find and fix them all.

You need

  • A Linux system with sudo access

Do first

Everything you need is in Days 01 to 04. No new commands.

Set up the scenario

Run this exactly as written. Do not read it as a hint — read it as a machine you inherited.

sudo groupadd -f devs
sudo useradd -m -s /bin/bash dana 2>/dev/null
sudo useradd -m -s /bin/bash eli 2>/dev/null
sudo usermod -G devs dana
sudo mkdir -p /srv/project/{src,build}
sudo chown root:root /srv/project
sudo chmod 750 /srv/project
sudo chmod 770 /srv/project/src
sudo chown root:devs /srv/project/src
sudo touch /srv/project/src/main.py
sudo chown dana:dana /srv/project/src/main.py
sudo chmod 640 /srv/project/src/main.py

The situation

dana and eli are both supposed to be able to enter /srv/project, and both edit files in /srv/project/src. Right now:

sudo -u dana ls /srv/project
sudo -u eli ls /srv/project
sudo -u dana sh -c 'echo "# edit" >> /srv/project/src/main.py'
sudo -u eli sh -c 'echo "# edit" >> /srv/project/src/main.py'

Some of those fail. Work out why each one fails before changing anything.

Your goal

When you are done, all four of these must succeed:

  1. dana can list /srv/project
  2. eli can list /srv/project
  3. dana can append to /srv/project/src/main.py
  4. eli can append to /srv/project/src/main.py

And this must still fail — you are fixing access for the team, not removing it for everyone:

5. A user who is not in devs can do none of the above.

Constraints

  • Do not use chmod 777 anywhere. If your fix involves 777, it is the wrong fix.
  • Do not change any file's owner to root.
  • eli must gain access by group membership, not by being named on anything.
  • New files created in src by either user must be group-editable by the other without a manual chmod afterwards.

There are four distinct faults

One is a group membership. One is the group on a directory. One is a mode on a directory. One is a mode on a file. Constraint five above is a clue about a fifth thing you might be tempted to change and should not.

Hints, in increasing order of spoiler

  • Check id dana and id eli and compare them to getent group devs. Day 02 warned about a specific flag.
  • Traversing a directory needs x for whoever is traversing. Look at both the mode and the group of /srv/project itself.
  • 640 on a file means the group may read. The goal says append.
  • The last constraint — new files inheriting the group — was the setgid demonstration in Day 02.

What success looks like

Verify

for u in dana eli; do sudo -u $u ls /srv/project >/dev/null 2>&1 && echo "$u list: ok" || echo "$u list: FAIL" sudo -u $u sh -c 'echo "# t" >> /srv/project/src/main.py' 2>/dev/null && echo "$u write: ok" || echo "$u write: FAIL" done # dana list: ok / dana write: ok / eli list: ok / eli write: ok

And the boundary still holds:

Verify

sudo useradd -m frank 2>/dev/null sudo -u frank ls /srv/project 2>&1 | tail -n 1 # ls: cannot open directory '/srv/project': Permission denied

Clean up

sudo rm -rf /srv/project
for u in dana eli frank; do sudo userdel -r $u 2>/dev/null; done
sudo groupdel devs 2>/dev/null

Where this goes next

Week 1 was about things at rest — files, accounts, bits. Week 2 is about things running: processes, the services that supervise them, the logs they write, and the network they sit on.