Accounts, sudo, and what a login reads
Domain 2 is 20% of XK0-006 and half of it is accounts. This guide reads the defaults before creating anything, makes a real user and shows where every file in its home came from, writes a sudo rule and validates it, breaks a rule on purpose to see what the checker says, and demonstrates which startup files a login shell reads that an ordinary one does not.
Services and Users Guide 12 of 28 Intermediate
- OSUbuntu 26.04 LTS
- Kernel7.0.0-30-generic
- systemd259
- Mandatory access controlAppArmor on Ubuntu, SELinux enforcing on Alma
- TimeAbout 24 min
- Firewallufw / nftables 1.1.6 - firewalld / nftables 1.1.5
| Server Name | IP Address | OS | Roles | CPU | RAM | HDD |
|---|---|---|---|---|---|---|
| LPLUS-A01 | 192.168.0.73 | Ubuntu 26.04 LTS | Debian-family host - apt, ufw, netplan, AppArmor | 2 Core | 4 GB | 50 GB |
This guide includes
Use this when granting someone limited administrative access, or when a script works interactively and fails from cron. This matters because an unvalidated sudoers file can lock every administrator out of a machine, and because a non-login shell never reads the profile that sets the PATH you were relying on.
- reading the useradd defaults and the login policy before creating an account
- creating a user and tracing every file in its home back to
/etc/skel - writing a sudo rule, validating it with
visudo -c, and testing what it does and does not allow - breaking a rule on purpose and reading the line and column the checker reports
- separating a login shell from a non-login shell, and seeing which files each reads
Before you start
- a-service-an-account-and-the-permission-between-them
-
What useradd will do, before it does it
-
A real account, and where its home came from
-
A sudo rule, checked before it is installed
-
A broken rule, and the check that catches it
-
What a login actually reads
-
Putting the machine back