A shared folder the whole team can use
The dev team shares /srv/projects, and the last "fix" was chmod 777. Set real group ownership, group collaboration rights, setgid inheritance, and lock everyone else out.
Scenario
The dev team collaborates in /srv/projects. It was created as root:root 755, so nobody could
write to it, and someone "fixed" that with chmod 777. Now every account on the box, including
the intern's scraper and whatever runs as nobody, can write (and delete) the team's work.
There's a developers group with exactly the right members. Use it.
Starting state
drwxrwxrwx root root /srv/projects (after the 777 "fix")
Your job
Write the commands in fix.sh (they are applied in order) so that:
- the directory is group-owned by
developers, - group members have full read/write/traverse access,
- the setgid bit is set, so files created inside inherit the
developersgroup instead of each author's primary group, - everyone outside the group has no access at all.
What "done" looks like
ls -ld /srv/projects shows drwxrws--- root developers, a developers member can create and
edit files, and any other user gets permission denied.
Teaches: group ownership, the setgid bit on directories, and why mode 777 is never the fix.
What gets checked
Your solution is verified against each of these:
- /srv/projects is group-owned by developers
- A developers member can read, write and enter the directory
- The setgid bit is set so new files inherit the developers group
- Users outside the group can neither read nor write it
Solve it in your browser
No setup, no install. Write your solution in the editor and hit Check. The in-house engine renders and grades it instantly, then issues your proof the moment every check passes.
Solve in browser →Prefer your own lab?
- Build the fix locally. New to the tooling? See setting up your lab.
- Push your topology file, device configs, and any playbooks to a public repo (GitHub or GitLab).
- Submit the repo link. We review it by hand, confirm it works, and issue your proof page.