We closed Module 4 with a list of debts, and this lesson settles the first and most uncomfortable one: svc-tramontana exists "by magic" and the tramontana group does not exist at all. You have been writing chown svc-tramontana:tramontana on files whose group nobody had ever created. That ends today. You are going to see what an identity really is in Linux — a number, not a name — which files are the source of truth and what each field contains, how person accounts and service accounts are created (they look nothing alike), and why the most expensive mistake in the whole module fits into a single missing letter: usermod -G instead of usermod -aG.

1. The identity model: UID, GID and supplementary groups
2. The four files of truth, field by field
3. Account types and the UID range in /etc/login.defs
4. Creating users: useradd, adduser and /etc/skel
5. Passwords: setting, locking and the meaning of ! and *
6. Modifying and deleting accounts, and orphaned files
7. Account expiry with chage
8. Groups: creating, modifying and why you have to log in again
9. Service accounts: why the app never runs as root
10. Auditing: who is who and who has logged in
11. Tramontana case: settling the previous module's debt

The kernel does not know what operator is. The kernel only handles numbers:

• UID (User ID): identifies the user. The owner of a file is a number stored in the inode, not a string.
• GID (Group ID): identifies a group. Every user has one primary group (the one a new file they create inherits) and zero or more supplementary groups.

Names exist only for our convenience, and the number→name translation is done by the system library reading /etc/passwd and /etc/group. That is why, if you delete a user, ls -l starts showing raw numbers: the file keeps UID 1003 even though nobody is called that any more.

Read it like this: operator is 1000, its primary group is operator (1000) and it also belongs to adm and sudo as supplementary groups. That distinction matters:

The primary group is defined in field 4 of /etc/passwd and is the one assigned to the files the user creates; the supplementary ones are defined in field 4 of /etc/group and only widen access. A process's effective group can be changed on the fly with newgrp or sg.

On Ubuntu, by default each user gets their own group with the same name (the UPG scheme, User Private Group). It is not a whim: it lets you work with umask 002 without exposing your files to half the machine, because "the group" is only you.

Seven fields separated by :. It is readable by everybody (644) because any process needs to translate a UID into a name for a simple ls -l.

Nine fields. Permissions 640, ownership root:shadow: readable by root and by the shadow group, invisible to everyone else. That is where the hash lives, and a hash readable by anybody is a hash somebody will eventually break with a GPU.

The hash has the format $id$parameters$salt$hash. On Ubuntu 24.04 the default algorithm is yescrypt ($y$), which replaced SHA-512 ($6$) because it resists GPU and ASIC attacks thanks to its memory cost:

Four fields: name, password (x), GID and list of supplementary members. Careful: anyone who has that group as their primary does not appear in that list. /etc/gshadow (640, root:shadow) holds the group password — an oddity almost nobody uses — and the group administrators, who can add members with gpasswd without being root.

The one deciding those ranges is /etc/login.defs:

The important part: UID 0 is root not because of the name, but because of the number. If you create a second account with UID 0, you have two roots and no audit trail able to tell them apart in the inode. Never do it.

useradd is the low-level tool of the shadow suite: it does exactly what you ask, not one thing more. Its key options:

adduser is a Debian Perl script that wraps useradd and does what a human expects: it picks a free UID, creates the home with the right permissions, creates the user's own group, copies /etc/skel, asks for the password and fills in the GECOS interactively. An honest comparison:

A practical rule: by hand, adduser; in a script, useradd, because its behaviour does not depend on a distribution-supplied configuration file.

/etc/skel (which on Ubuntu contains .bashrc, .profile and .bash_logout) is the home template: everything inside it is copied when the account is created with -m. It is the place to impose a corporate .bashrc or the red production prompt from Module 3.

Locking and unlocking:

The L from passwd -S means "locked"; P would be a usable password and NP no password, which is an emergency.

usermod -L does the same as passwd -l to the hash. The practical difference is not between them, but in what neither of them does: locking the password does not prevent logging in with an SSH key, nor does it kill open sessions. For a real staff departure you need the full combination:

-e 1 sets the expiry to 2 January 1970: the account is expired and PAM rejects access whichever way it comes.

usermod changes what already exists. And here is the module's classic mistake:

Without the -a (append), operator drops out of sudo and out of adm at the same instant. And if the root session was closed as well, you have just lost administration of the machine and it is time to boot into recovery mode. Always check before and after with id.

Other common uses:

Deleting:

userdel -r does not find what the user left outside their home: a file in /srv, a cron job, a temporary file. Those files are left with a nameless UID and, worse still, the next user who receives that UID will inherit their ownership. A mandatory audit before reassigning:

Compliance warning. Staff onboarding and offboarding are not an isolated technical task: in a real environment they must follow an approved procedure (who authorises it, within what deadline access is revoked, what is done with the employee's files, which may contain guests' personal data). Document every onboarding and every offboarding with a date and the person who authorised it, and have the security or compliance officer (GDPR) validate the procedure before you apply it.

chage handles fields 3 to 8 of /etc/shadow without you having to count days since 1970.

The real password policy — minimum length, complexity, dictionary, history — does not live here: it is imposed by PAM with pam_pwquality, and it is the subject of 06-06. chage only sets the deadlines.

gpasswd -a and usermod -aG do the same thing; gpasswd has the advantage of not allowing the forgotten--a mistake, because its syntax is always additive.

And now the detail that costs people whole afternoons: adding somebody to a group does not affect their open sessions.

The reason is that supplementary groups are set at login time, get recorded in the process's credentials and are inherited by its children. No configuration file is going to change a process that is already running. The ways out:

The right thing to do is log out and log back in. And the same applies to services: if you change the groups of svc-tramontana, you have to restart the service, reloading is not enough.

An application exposed on port 8080 is the most likely way into your server. If it runs as root, any remote execution flaw is game over: the whole machine. If it runs as svc-tramontana, the attacker inherits an identity that cannot read /etc/shadow, cannot write to /etc, cannot install anything and cannot read other users' files.

What distinguishes a service account:

• A system UID (-r, below 1000) and no expiry: a service account that expires brings the service down at three in the morning.
• No login shell: /usr/sbin/nologin (which prints a message and exits with an error) or /bin/false.
• No usable password (! or * in shadow) and no home of its own: it normally points at the application directory.

getent is always preferable to grep /etc/passwd: the day the company adds a corporate directory, grep will lie and getent will still be telling the truth.

The starting state on srv-tramontana: operator (1000) and luis (1001) exist; svc-tramontana and the tramontana group do not, even though half a module talked about them. We fix it in order, and with a prior backup of the identity files as the course's convention requires.

-M stops the home being created: /opt/tramontana already exists and we do not want useradd dumping /etc/skel on top of it. We verify before touching anything else:

Now the ownership of the directories, which until today was a promise:

Notice the o=: nobody outside the group sees anything, applying the convention of "a shared group instead of permissions for others". That 2 in 2770 on uploads is the SGID bit, which makes everything created inside belong to the tramontana group regardless of who creates it; we take it apart in the next lesson.

And the documentation, which is part of the job:

• usermod -G without -a. The most expensive mistake in the lesson: it replaces the whole list and can throw you out of sudo. Before touching groups, save the output of id user; afterwards, compare it.
• Expecting a new group to work in the current session. It will not. id user queries the database, plain id queries your session. Log out and back in, and restart the affected services.
• Editing /etc/passwd or /etc/shadow with nano. Use vipw and vipw -s (and vigr for the groups): they lock the file and validate the syntax on exit. A corrupt shadow is a server nobody can get into.
• Creating the service account with a shell. If svc-tramontana has /bin/bash, any route that manages to execute as that user gets an interactive shell. nologin is not cosmetic.
• Confusing locking with disabling. passwd -l does not prevent access with an SSH key. For a departure: usermod -L -e 1 -s /usr/sbin/nologin and pkill -u. And do not reuse the UID of a deleted account without auditing first with find -uid.
• Tip: set the service UIDs and GIDs (997, 1002) explicitly and write them down. The day you restore a backup on another machine, the numbers have to match or the permissions will slip out of place across the board.

1. A complete intern onboarding. Create the intern account with useradd: its own home, a Bash shell, GECOS "Operations Intern", supplementary member of tramontana, a password that must be changed at first login and an account expiry of 31 December 2026. Verify everything without logging in as them.
2. Diagnosing a disaster. Somebody has run sudo usermod -G tramontana operator. Describe the exact symptom operator will see at their next login, how you would confirm it and how you repair it if you no longer have sudo.
3. Account audit. Write a command that lists, from /etc/passwd, only the person accounts (UID ≥ 1000, excluding nobody) with their shell, and another that detects accounts with an empty password in /etc/shadow.

1.

Here -G without -a is correct, because the account is being created and there are no previous groups to lose. The -a only matters in usermod.

2. The symptom: operator logs in normally, but any sudo answers operator is not in the sudoers file. This incident will be reported., and on top of that they lose the read access to the logs that adm gave them. Confirmation:

4(adm) and 27(sudo) are missing. Repair with privileges: sudo usermod -aG adm,sudo operator and log in again. Without sudo and without another administrator account there is no shortcut from inside: you have to reboot the VM, edit the GRUB entry to boot with init=/bin/bash, remount the root filesystem with mount -o remount,rw / and run usermod -aG adm,sudo operator. That recovery procedure is covered in depth in 07-01; the fact that it exists is precisely why physical access, or access to the VM's console, is in itself administrator access.

3.

Silence in the output means there are none, which is exactly what you want to see: the "silence if all is well" convention applied to an audit.

There is no magic left in the identities on srv-tramontana. You know that a user is a number; you read the nine fields of /etc/shadow, you recognise a $y$ yescrypt hash and you tell !, * and the empty field apart; you separate system accounts from person accounts by the UID range in /etc/login.defs; you create accounts with useradd in scripts and with adduser by hand, knowing what /etc/skel contributes; you set deadlines with chage and leave the password policy for 06-06; and you have taken on board that usermod -G without -a is a quick way to lose the machine and that a new group does not exist until the session is reopened.

And, above all, you have settled the debt: the tramontana group (gid 1002) exists, svc-tramontana (uid 997) is a real system account with no shell and no password, operator and luis are in the group, /opt/tramontana and /srv/tramontana/backups have an owner and the change is written down in the HISTORY.

The other half of the equation is missing. You have identities, but sudo is still a magic word you type without knowing who decides what it lets you do, and the odd bits you glimpsed in 02-07 — that s instead of the x — are still unexplained, even though you have just used one by setting 2770 on uploads. In the next lesson, sudo and Special Permissions, both of those end: you will write a sudoers rule that lets operator restart and deploy the application without being root, you will really understand SUID, SGID and the sticky bit, you will replace a SUID with capabilities so that the app can listen on port 80, and you will give Luis access to the logs with an ACL without putting him in the adm group.