Linux Users and Permissions
You learn the Linux user and permission system: create users and groups, grant sudo access, set file ownership and access rights, and understand SUID risks. Essential for every server admin and a mandatory IHK exam topic. 5 tasks, about 60 minutes.
Manage users, groups, and file permissions
Users, groups and permissions on Linux
On a Linux server every file has an owner and a group, and every process runs under a user account with certain rights. Splitting the system up cleanly prevents a single compromised account from endangering the whole server — the principle of least privilege.
Key terms
- User: an account that processes run under.
rootis the administrator with all rights. - Group: bundles several users to grant them rights together.
- Permissions: define who may read (r), write (w) or execute (x) a file — separately for owner, group and everyone else.
sudo: lets a normal user run individual commands with administrator rights.
Your goal in this lesson
You build a typical company-server structure: a developer group, a user in it, a shared project directory with correct group permissions, a targeted sudo rule — and you track down risky SUID programs. A mandatory IHK exam topic.
Exercises
1. Create group 'devs'
Concept: group. Groups bundle users with the same rights. Instead of granting rights to each person individually, you grant them once to the group — the basis of clean permission management.
Create a group named
devs:sudo groupadd devsCheck:
getent group devsoutputs a line starting withdevs:.2. Create user 'developer' and assign to group
Concept: user & group membership. A new user only belongs to the
devsgroup if you assign them explicitly. The-malso creates their home directory (/home/developer), which they need for their own files.Create the user
developerand add them to thedevsgroup:sudo useradd -m -G devs developerCheck:
id developershowsdeveloperanddevsamong the groups;/home/developerexists.3. Project directory with group permissions
Concept: ownership & the SGID bit. Group ownership decides who may write in a directory. The SGID bit (the leading
2in2775) makes new files automatically inherit the directory's group — otherwise every new file belongs to the creator's group and the team loses access.Create the directory, set owner and permissions:
sudo mkdir -p /opt/project sudo chown root:devs /opt/project sudo chmod 2775 /opt/projectCheck:
stat -c '%U:%G %a' /opt/projectyieldsroot:devs 2775.4. sudo access for devs group
Concept: targeted
sudorule (NOPASSWD). Instead of full admin access, you allow thedevsgroup exactly one command without a password — least privilege. Such rules belong in separate files under/etc/sudoers.d/.Create the file (
sudo nano /etc/sudoers.d/devs) with the content:%devs ALL=(ALL) NOPASSWD: /bin/systemctl restart nginx⚠️ Always check the syntax with
sudo visudo -c -f /etc/sudoers.d/devs— an error in a sudoers file can locksudocompletely.Check:
/etc/sudoers.d/devscontains a%devsrule withNOPASSWDforsystemctl restart nginx.5. Find SUID binaries
Concept: SUID. A SUID program runs with the rights of its owner (often
root) instead of the caller's. Example:/usr/bin/passwdmay change your password in/etc/shadow(root only). SUID is necessary, but any flaw in it means instant privilege escalation — so you take stock (an audit).Find all SUID programs and write them to an audit file:
find / -perm -4000 -type f 2>/dev/null > /home/student/suid-audit.txt-perm -4000filters the SUID bit;2>/dev/nullsuppresses errors about locked directories.Check:
/home/student/suid-audit.txtis not empty and contains/usr/bin/passwdamong others.
Now practice it yourself
Reading is good – doing is better. Start this course on a real Linux VM, right in your browser. A free account is all it takes.
Start for freeLab content under CC BY 4.0 – free to use with attribution (© TechLogia).
