Users, Groups & sudo

Every program on Linux runs as some user, and every file belongs to one. The permissions you learned in the previous lesson only make sense once you know how users and groups are created and managed, and how a normal user borrows administrator power for a single command with sudo.

In this lesson you will inspect your own account, add a new user, put users into groups, and learn the safe way to grant and use admin rights.

Who am I?

whoami
id
groups

priya
uid=1000(priya) gid=1000(priya) groups=1000(priya),4(adm),24(cdrom),27(sudo),30(dip),46(plugdev),100(users)
priya adm cdrom sudo dip plugdev users

Linux identifies users and groups by numbers. The UID (user ID) is Priya's number, 1000, the first normal account on Ubuntu. The GID is her primary group, also priya. She is a member of several supplementary groups: sudo lets her use sudo, and adm lets her read most log files. The superuser root always has UID 0; system accounts for services, such as www-data for web servers, use numbers below 1000.

Where accounts are stored

Account information lives in three plain text files:

• /etc/passwd holds one line per account. Everyone can read it, and despite the name it contains no passwords.
• /etc/shadow holds the password hashes (scrambled, one-way versions of passwords) and expiry rules. Only root can read it.
• /etc/group lists each group and its members.

grep priya /etc/passwd
getent group sudo

priya:x:1000:1000:Priya Sharma:/home/priya:/bin/bash
sudo:x:27:priya

The passwd line has seven fields separated by colons: user name, x (meaning "the password is in shadow"), UID, GID, a comment (usually the full name), the home directory and the login shell. Service accounts often have /usr/sbin/nologin as their shell so nobody can log in as them. getent looks up an entry in any account database, including network directories, so it is better than grep in scripts.

Adding and removing users

Ubuntu offers two tools. adduser is the friendly one: it creates the home folder, copies starter files from /etc/skel, and asks for a password. useradd is the low-level tool that does only what its options say; scripts and other distributions use it.

sudo adduser kabir

info: Adding user `kabir' ...
info: Selecting UID/GID from range 1000 to 59999 ...
info: Adding new group `kabir' (1001) ...
info: Adding new user `kabir' (1001) with group `kabir (1001)' ...
info: Creating home directory `/home/kabir' ...
info: Copying files from `/etc/skel' ...
New password:
Retype new password:
passwd: password updated successfully
Changing the user information for kabir
Enter the new value, or press ENTER for the default
        Full Name []: Kabir Singh
...
Is the information correct? [Y/n] y

The same result with useradd takes options: sudo useradd -m -s /bin/bash -c "Kabir Singh" kabir followed by sudo passwd kabir. Without -m there is no home folder, and without -s the shell may be the very limited /bin/sh.

Other everyday commands:

sudo: admin power for one command

On Ubuntu the root account has no password set, so nobody can log in as root directly. Instead, members of the sudo group put sudo in front of a command to run just that command as root. sudo asks for your own password (not root's), remembers it for a few minutes, and records what you ran in the system log.

apt update
sudo apt update
sudo -u www-data whoami
sudo -l

Error: Could not open lock file /var/lib/apt/lists/lock - open (13: Permission denied)
...
www-data
User priya may run the following commands on laptop:
    (ALL : ALL) ALL

The first command fails because updating package lists needs root. The second works. sudo -u www-data runs a command as a different user, useful for testing what the web server can see. sudo -l lists what you are allowed to run; (ALL : ALL) ALL means anything, as any user and group.

For a longer admin session, sudo -i opens a root shell (the prompt changes to #); type exit to leave it. The older command su switches user too, but it asks for the target user's password, which is why Ubuntu prefers sudo.

Advanced: writing sudoers rules

sudo's rules live in /etc/sudoers and in small files inside /etc/sudoers.d/. Never edit them with a normal editor: a single typo can lock everyone out of sudo. Use visudo, which checks the syntax before saving.

sudo visudo -f /etc/sudoers.d/deploy

# Kabir may restart the web server without a password, and nothing else
kabir ALL=(root) NOPASSWD: /usr/bin/systemctl restart nginx

The format is: who, on which hosts (ALL), as which user (root), then the exact command. Giving a deploy account one specific command is far safer than adding it to the sudo group. Be careful with commands that can start a shell or edit any file (such as vim, less or bash): permitting them is the same as giving full root access.

Common mistakes

• Using usermod -G without -a. It wipes the user's other groups.
• Expecting group changes to apply immediately. Log out and back in (or start a new SSH session) after usermod -aG.
• Working in a root shell all day. Use sudo for single commands so every risky step is deliberate and logged.
• Editing /etc/sudoers with nano directly. Use visudo, which refuses to save a broken file.
• Sharing one account between people. Give everyone their own user, so permissions and logs show who did what.

Key points

• Users and groups are numbers (UID, GID); root is UID 0 and normal Ubuntu users start at 1000.
• /etc/passwd lists accounts, /etc/shadow holds password hashes, /etc/group lists groups.
• adduser creates a complete user on Ubuntu; usermod -aG group user adds a group without removing others.
• sudo runs one command as root using your own password; sudo -l shows your rights and sudo -u runs as another user.
• Ubuntu 26.04 uses sudo-rs; edit sudo rules only with visudo.

sudo adduser meera
sudo addgroup designers
sudo usermod -aG designers meera
id meera
sudo visudo -f /etc/sudoers.d/designers

uid=1002(meera) gid=1002(meera) groups=1002(meera),100(users),1003(designers)

%designers ALL=(root) /usr/bin/systemctl restart nginx