DevOpsSecurityLinuxUserssudo

Users, Groups and sudo

K
Kai··4 min read
Linux From Basics to ProficiencyPart 13 of 18
PreviousSoftware Package Management: apt, dnf, apkNextBasic Networking on Linux

Linux is a multi-user operating system from the ground up: many people can share one machine, each with their own identity and permissions (recall Article 7 — permissions are based on user/group). This article covers how to manage users and groups, and sudo — the safe way to work with administrative privileges.

Where users are stored: /etc/passwd

Every user on the system lives in /etc/passwd, one line per user:

grep root /etc/passwd

root:x:0:0:root:/root:/bin/bash

Seven fields, separated by ::

root : x : 0 : 0 : root : /root : /bin/bash
 │     │   │   │    │       │         │
name  pass UID GID GECOS   home      shell
     (x = in (num (primary (descr.) (home   (shell at
     shadow) ID) group)            dir)    login)
  • UID 0 is root — the superuser, full privileges, bypasses every permission check. Regular users have a UID from 1000 up.
  • The password field is x — the real (hashed) password isn't here, it's in /etc/shadow.
  • shell: the program run when the user logs in. Notice many system users have the shell /usr/sbin/nologin — meaning they cannot log in, they only run services (for example www-data runs the web server). This is a security practice: services run as their own user that cannot log in.

Passwords: /etc/shadow

The (hashed) passwords live in /etc/shadow, and this file is readable only by root:

ls -l /etc/shadow

-rw-r----- 1 root shadow 529 ... /etc/shadow

Splitting passwords into a separate root-only file is a security layer: /etc/passwd is readable by everyone (many programs need it), but the password hashes are not. You rarely edit this file by hand — use the passwd command.

Groups: /etc/group

A group bundles multiple users to grant shared permissions (recall Article 7 — permissions have a "group" column):

grep dev /etc/group

dev:x:1001:alice

Each user has one primary group (assigned at creation) and can belong to multiple supplementary groups. A real-world example: add a user to the docker group to run docker without sudo (Article 1 of the Docker series), or the sudo group to be allowed to use sudo (below).

Creating and managing users

groupadd dev                                # create a group
useradd -m -s /bin/bash -G dev alice         # create user alice
passwd alice                                 # set a password for alice

Common useradd flags:

  • -m — create the home directory (/home/alice). Forget -m and the user has no home.
  • -s /bin/bash — set the login shell.
  • -G dev — add to the supplementary group dev.

Check:

id alice

uid=1001(alice) gid=1002(alice) groups=1002(alice),1001(dev)

Other management commands: usermod (modify a user, e.g. usermod -aG docker alice adds a group), userdel -r alice (delete user along with home), groupadd/groupdel.

On some distros/configs, adduser/addgroup (friendly, interactive scripts) are preferred over useradd/groupadd (low-level). The result is the same.

su: switch to another user

su (switch user) lets you become another user:

su alice -c "whoami"     # run a single command as alice
su - alice               # open a full login shell as alice

alice

su with no name switches to root (requires the root password). The dash (su - alice) creates a clean login environment (correct PATH, environment variables, and that user's home directory).

sudo: doing administrative work the right way

To run a command that needs root privileges (installing software, editing system files), you should not log in directly as root. Instead use sudo — run one command with root privileges:

sudo apt update              # run apt update as root
sudo systemctl restart nginx

(On default Ubuntu you may need to install it: apt install sudo, then add the user to the allowed group: usermod -aG sudo alice.)

Why sudo beats logging in as root

This is an important security principle (same idea as "least privilege" in earlier series):

  • Audit trail: every sudo command is logged (/var/log/auth.log) — you know who ran what, when. Logging in as root leaves no trace of who it was.
  • Least privilege: you do day-to-day work as a regular user (less risk of a slip), and only "elevate" for the specific commands that need root. Staying logged in as root means one mistyped command (rm -rf in the wrong place) is a disaster.
  • No shared root password: each person uses their own password to sudo (you enter your password, not root's), so nobody needs to know a shared root password. To revoke someone's access, just remove them from the sudo group.

Who can sudo is defined in /etc/sudoers (edit with visudo to avoid a broken write). Usually it's enough to add the user to the sudo group (Debian/Ubuntu) or wheel (Fedora/RHEL).

Pragmatic rule on a server: create a regular user for yourself, add it to the sudo group, then disable direct root login (over SSH — Article 14). Do all administration via sudo.

🧹 Cleanup

userdel -r alice 2>/dev/null
groupdel dev 2>/dev/null

Wrap-up

Linux is multi-user: users live in /etc/passwd (7 fields, UID 0 = root), hashed passwords in /etc/shadow (root-only), groups in /etc/group. Create/modify with useradd/usermod/passwd/groupadd, inspect with id. su switches identity; sudo runs one command with root privileges — and you should prefer sudo over logging in as root because of the audit trail, least privilege, and no shared root password.

You can now manage local users. Article 13 steps out onto the network: the basic networking commands on Linux — checking IP, ports, connections, DNS.

Linux From Basics to ProficiencyPart 13 of 18
PreviousSoftware Package Management: apt, dnf, apkNextBasic Networking on Linux

Related Posts

The Tetragon Way: From Observe to Enforc...
SecurityKubernetes

The Tetragon Way: From Observe to Enforce with bpf_send_signal

Tetragon is the Cilium ecosystem's runtime security tool: it observes with kprobe/tracepoint (the very hooks Part II used) and then enforces inside the kernel. Its enforcement uses two helpers — bpf_send_signal sends SIGKILL to kill a process, and bpf_override_return overrides a syscall's return value. This article rebuilds that: an exec tracepoint calls bpf_send_signal(SIGKILL) the moment a process runs — a forbidden binary gets exit 137, a normal binary still runs. No LSM, no reboot.

K
KaiMay 24, 2026· 1 views
LSM BPF: Enforcing Security Right Inside...
SecurityLinux

LSM BPF: Enforcing Security Right Inside the Kernel

So far our eBPF has only observed. LSM BPF enforces: it attaches to the kernel's security hooks (Linux Security Modules) that SELinux and AppArmor use, and a program returns 0 to allow or -EPERM to block. This article writes an LSM program that blocks opening a file, and hits a lesson: it loaded and attached but blocked nothing — because bpf wasn't an active LSM. After enabling bpf via a boot parameter and rebooting, it blocks for real — both cat and python get Operation not permitted.

K
KaiMay 24, 2026