sudo, sudoers & the Account Files

In one line

Where Linux keeps users, groups, and password hashes (/etc/passwd, /etc/shadow, /etc/group), how su differs from sudo, and how to grant exactly the admin rights someone needs through sudoers, safely.

0/7 · 0%

Think of it like this

Real-life example: su is borrowing the building manager's master key for as long as you like; sudo is asking the front desk to open one specific door for you, with your name written in the logbook. That's why servers use sudo: least privilege plus an audit trail.

Key ideas

01
/etc/passwd (world-readable) has one line per account: name:x:UID:GID:comment:home:shell. The x means the password hash lives elsewhere. UID 0 is root; system/service accounts usually have UIDs below 1000 and a shell of /usr/sbin/nologin.
02
/etc/shadow (readable only by root) holds password hashes and ageing rules (chage -l <user> shows them). /etc/group lists groups and their members. Never edit these by hand: use useradd, usermod -aG, passwd, groupadd, and vipw/vigr if you must.
03
su - <user> switches to another user with THEIR password (root's, for su -), giving a full shell as them. sudo <command> runs one command as root (or another user) using YOUR password, and logs it (/var/log/auth.log on Ubuntu, journalctl -t sudo). sudo -i opens a root shell when you genuinely need several commands.
04
Who may use sudo is defined in /etc/sudoers and files in /etc/sudoers.d/. ALWAYS edit with visudo (or visudo -f /etc/sudoers.d/deploy): it checks syntax before saving, and a broken sudoers file can lock every admin out of sudo. On Ubuntu, members of the sudo group get full sudo; on RHEL-family systems it's the wheel group.
05
Rule format: who where=(as_whom) what. %devops ALL=(ALL:ALL) ALL gives a group full sudo. Least-privilege example: deploy ALL=(root) NOPASSWD: /usr/bin/systemctl restart shoplite-api lets a CI deploy user restart ONE service and nothing else. NOPASSWD is convenient for automation but should always be paired with a narrow command list.
06
Common mistakes: allowing commands that can spawn a shell (editors, less, scripting interpreters, find -exec), which effectively grants full root; wildcards in command arguments; and giving service accounts a login shell. Keep rules in separate files under sudoers.d/ so config management (Ansible, GitOps course) can own them.

Code & diagrams

inspect accounts and sudo rightsbash

getent passwd deploy                 # deploy:x:1001:1001::/home/deploy:/bin/bash
sudo getent shadow deploy | cut -d: -f1,3-5
id deploy                            # uid=1001(deploy) gid=1001(deploy) groups=1001(deploy)
sudo -l -U deploy                    # what may deploy run with sudo?

/etc/sudoers.d/deploy (edit with: sudo visudo -f /etc/sudoers.d/deploy)text

# CI deploy user: restart and check one service, nothing else
deploy ALL=(root) NOPASSWD: /usr/bin/systemctl restart shoplite-api, /usr/bin/systemctl status shoplite-api

# Ops team: full sudo, password required, logged
%ops ALL=(ALL:ALL) ALL

Explain it without notes

Why is sudo preferred over sharing the root password?

Why must you use visudo instead of a normal editor?

Practice

Write a sudoers rule letting the backup user run only /usr/local/bin/pg-backup.sh as the postgres user without a password.

Trade-offs

↔
Broad sudo is convenient but makes every compromised account a root compromise; narrow rules take more maintenance. In the cloud, prefer short-lived, audited access (SSM Session Manager, IAM Identity Center) over long-lived sudo users where possible.

Done when you can

I can explain the fields of /etc/passwd and why hashes live in /etc/shadow
I always edit sudoers with visudo, using files in /etc/sudoers.d/
I can write a least-privilege sudo rule for an automation user