Linux: users, groups and permissions

Two operations staff and an accountant start on Monday. Today everyone logs in with the same admin account, whose password is written on a sticky note. The statutory auditor has set three conditions before signing off the year: named accounts, access to the accounting records limited to the people concerned, and traceability of administrative actions. You have the weekend. Managing rights is what gets handed to a junior administrator first, and what is most often done wrong: a chmod 777 that solves today's problem and opens this year's. You will start with the audit, and it holds a surprise: a former employee has kept full powers. Then you will translate the business need into groups, build a share where every new file stays editable by the whole team (group, setgid, umask), and grant one precise command through sudo instead of root power. The server is in production, and the order of your moves matters as much as the moves themselves: build, prove under each newcomer's identity, and only then close the old accesses. The guide makes you predict the result before every command, because the gap between what you expected and what you see is what makes Unix permissions click. At the end, the machine's state is checked and counts for your ranking. Sandbox ready, terminal in the browser, no key to manage.