Log into a fresh Linux box as the account you made during install, change a file the system owns, and you get stopped cold:

$ nano /etc/hosts
Error writing /etc/hosts: Permission denied
$ whoami
priya
$ id
uid=1000(priya) gid=1000(priya) groups=1000(priya),27(sudo)

Nothing is broken. That file belongs to root, your account does not, and the kernel checked before letting the write through. That single refusal is the whole subject of this part. Every action on a Linux system is allowed or denied based on three things: which user you are, which groups you belong to, and whether you were granted the right to act as root through sudo. The numbers in that id output, 1000 and 27, are how the kernel actually tracks it. Names are for humans.

Two people will get something out of this. The recent graduate on a home VM should run every command below as a normal user first, then with sudo, and watch what changes. The admin who already types sudo fifty times a shift can skip to the sudoers section, because that is where the real incidents come from. Everything here works the same on Ubuntu, Debian, and the RHEL family, with the one distribution difference called out where it matters.

What a user actually is

A user account is one line in /etc/passwd with seven colon separated fields. Read that line and you know almost everything about the account.

Pull your own line with grep or, better, getent, which also reads accounts that come from a directory service and not just the flat file:

$ getent passwd priya
priya:x:1000:1000:Priya R:/home/priya:/bin/bash

The third field, the UID, is the part the kernel cares about. When you own a file, the disk records your UID, not your name. Rename the account and the files still point at 1000. Delete the account and create a new one that happens to get 1000, and the new account silently owns the old files. That is why UID reuse on shared servers is a quiet source of access bugs.

Root, and the map of UID numbers

Not every account is a person. Most accounts on a running server exist so that a service like the web server or the database can own its files and processes without any human ever logging in as them. Linux keeps people and services apart by number.

Root is UID 0. The kernel gives UID 0 a pass on the normal permission checks, which is why root can write any file and kill any process. Below 1000 sit the system accounts, most of them with a login shell of /usr/sbin/nologin so nobody can sign in as them. From 1000 up are the accounts real people use. Those boundaries are not magic numbers baked into the kernel; they come from /etc/login.defs, where UID_MIN defaults to 1000 and UID_MAX to 60000 on both Debian and RHEL families. List the service accounts on your box with one line of awk:

$ awk -F: '$3 < 1000 {print $3, $1}' /etc/passwd | head
0 root
1 daemon
2 bin
3 sys
33 www-data
100 systemd-network

Where passwords really live

The x in the password field of /etc/passwd is a placeholder. The actual password hash sits in /etc/shadow, a file that only root can read. That split is the single most important security decision in the whole account system, so it is worth seeing directly. As a normal user you cannot read it at all; that is the point.

$ cat /etc/shadow
cat: /etc/shadow: Permission denied
$ sudo getent shadow priya
priya:$y$j9T$Q0h8...redacted...:19845:0:99999:7:::
$ ls -l /etc/shadow
-rw-r----- 1 root shadow 1043 Jul  1 09:12 /etc/shadow

The hash field starts with a marker for the algorithm. On current Debian and Ubuntu that is $y$ for yescrypt; older systems show $6$ for SHA-512. The trailing numbers are password aging fields: last change, minimum days, maximum days, warning period. If the hash field ever holds a single ! or *, the account has no valid password and cannot log in with one, which is normal for service accounts. Here are the four files that run the whole show.

Groups, and why you belong to more than one

A group is just a named bag of users. Files and directories are owned by one user and one group, so group membership is how several people share access without anyone handing out a password. Every user has exactly one primary group, the GID in field four of the passwd line, and any number of supplementary groups listed in /etc/group.

$ id priya
uid=1000(priya) gid=1000(priya) groups=1000(priya),27(sudo),999(docker)
$ getent group sudo
sudo:x:27:priya,ravi

Being in the sudo group is what let this account run sudo in the first place. On the RHEL family the same job is done by a group called wheel. That one naming difference trips up people moving between distributions, so keep it in mind: sudo on Debian and Ubuntu, wheel on RHEL, Rocky, Alma, and Fedora. Cloud platforms rebuild this same idea as identity and access management, where users become groups and policies replace file permissions; if you have read the Cloud IAM part of the Cloud for Beginners series, the shape will look familiar.

Creating and changing accounts

There are two tools for making a user, and choosing wrong wastes ten minutes. useradd is the low level command present on every distribution. It does exactly what you tell it and nothing more, so on its own it will not make a home directory or set a password unless you ask. adduser, on Debian and Ubuntu, is a friendly script wrapped around useradd that asks questions, creates the home directory, and sets the password for you. On RHEL systems adduser is just a symlink to useradd, so it is not interactive there.

# Debian and Ubuntu, interactive, makes the home dir for you
$ sudo adduser ravi

# Portable form, explicit, works everywhere
$ sudo useradd -m -s /bin/bash ravi
$ sudo passwd ravi

The usermod trap that removes access

To add an existing user to a group you use usermod -aG. The -a means append. Leave it out and -G replaces the user list of supplementary groups with only the ones you named, quietly dropping every other group the user had. On a real box that means someone runs one command and loses sudo, docker, and anything else at once.

$ id ravi
uid=1001(ravi) gid=1001(ravi) groups=1001(ravi),27(sudo)

# WRONG: no -a, this REPLACES the group list
$ sudo usermod -G docker ravi
$ id ravi
uid=1001(ravi) gid=1001(ravi) groups=1001(ravi),999(docker)   # sudo is gone

# RIGHT: append and keep what was there
$ sudo usermod -aG docker ravi

su, sudo, and becoming root

There are two ways to run something with more power than your own account. This is the part worth slowing down on, because the difference between them is the difference between a system you can audit and one you cannot.

With su you switch into another account for a whole session, and you must know that account password. su - gives you a full root shell, which means every command after it runs as root until you type exit. With sudo you run one command as root, you authenticate with your own password, and the invocation is recorded. On a shared server that record is the whole game: after the fact you can see who ran what.

How sudo decides, and how to edit the rules

The rules live in /etc/sudoers and in drop-in files under /etc/sudoers.d/. You never open that file in a plain editor. You run visudo, which checks your changes for syntax before it saves. A broken sudoers file can lock every account out of sudo at once, and visudo is the seatbelt against that. A single rule reads like this:

# Edit safely, never with a bare text editor
$ sudo visudo

# The group rule that ships on Ubuntu, in /etc/sudoers
%sudo   ALL=(ALL:ALL) ALL

# A scoped drop-in: let ravi restart only nginx, no password
$ sudo visudo -f /etc/sudoers.d/ravi-nginx
ravi  ALL=(root) NOPASSWD: /bin/systemctl restart nginx

Read the group line as: members of the sudo group, on any host, may run any command as any user or group. The scoped drop-in is the better pattern for real work. Instead of handing someone the keys to everything, you grant the one command their job needs. The % in front of a name means the rule targets a group rather than a single user.

A real opinion, sudo -i over sudo su –

Half the tutorials online tell you to type sudo su - to get a root shell. Skip that habit. If you want a full root shell, sudo -i does it in one tool, sets up root environment the same way a real login would, and leaves a clean record of who asked. Chaining sudo into su just stacks two programs to reach what one already gives you, and it muddies the audit trail. The other line I will hold: do not scatter NOPASSWD: ALL across your sudoers. On your own throwaway VM it is a convenience nobody will ever question. On a shared server it means anyone who gets your shell, through a stolen key or a walk-past laptop, is instantly root with no second check. Grant NOPASSWD to specific commands, not to everything.

Questions I actually get

I added myself to a group but nothing changed. Why?
Group membership is read when your session starts. The change is real, but your current shell has an old view. Log out and back in, or run newgrp for that group.

Should I just log in as root to save time?
No. Use your own account and sudo. It keeps a record of who did what and stops one typo as root from wiping the box with no warning. Direct root login over SSH is usually disabled for exactly this reason.

What is the difference between a primary group and a supplementary group?
Your primary group is the GID in your passwd line and it becomes the group owner of files you create. Supplementary groups only grant access. You have exactly one primary and any number of supplementary.

useradd or adduser, which should I learn?
Learn useradd with its flags, because it works on every distribution. Reach for adduser on Debian and Ubuntu when you want the interactive shortcut. On RHEL they are the same command anyway.

Users and groups decide who you are. The next part is about what those identities are allowed to do to a given file: the read, write, and execute bits, and the octal numbers behind chmod. Once permissions click, the earlier Permission denied stops being a wall and becomes a sentence you can read. Working through the whole path from zero? Start at the Linux for Beginners guide, and if you want to see where all of this lands in a data center, the VMware for Beginners series covers the machines these accounts live on.

References

passwd(5) manual page, the /etc/passwd format
login.defs(5), UID_MIN and UID_MAX defaults
sudoers manual, the rule syntax

About The Author

Dr. Pranay Jha

Dr. Pranay Jha is a Cloud and AI Consultant with 18+ years of experience in hybrid cloud, virtualization, and enterprise infrastructure transformation. He specializes in VMware technologies, multi-cloud strategy, and Generative AI solutions. He holds a PhD in Computer Applications with research focused on Cloud and AI, has published multiple research papers, and has been a VMware vExpert since 2016 and a VMUG Community Leader.

See author's posts