In 02-07 you saw an s where you expected an x and I promised you would understand it thoroughly in this lesson. The moment has arrived, and it comes together with the other piece you have been using for four modules without asking any questions: sudo. You type sudo dozens of times a day, but who decided you could? Where is it written down? What would happen if Marta asked you to let luis restart the application — just restart it — without handing him the whole machine? This lesson answers all three questions and adds the tools the classic ugo/rwx model does not cover: capabilities, ACLs and immutable attributes. By the end, operator will be able to deploy Tramontana with a sudoers rule you wrote yourself, and Luis will read the logs without being in adm.

1. Why you do not work as root
2. su, su -, sudo -i and sudo -s compared
3. sudo in depth: the cache, the environment and the redirection mistake
4. sudoers: syntax, visudo and safe rules
5. Traceability: where sudo leaves its trace
6. Recovering from a broken sudoers
7. SUID: real UID versus effective UID
8. SGID on directories: the teamwork bit
9. The sticky bit and /tmp
10. Capabilities: the modern replacement for SUID
11. ACLs: permissions ugo cannot express
12. Extended attributes and immutability
13. Tramontana case: the deployment sudoers rule

Root does not have permissions: root has no permission checking. Faced with a process whose effective UID is 0, the kernel skips the whole verification. That means three things:

• A mistake is irreversible. rm -rf /opt/tramontana / with one space too many, run as operator, fails with "Permission denied" on the second path. Run as root, it wipes the system.
• There is no traceability. If five people share the root password, auth.log will say "root did X" and nobody will know who it was. With sudo, it will say "operator ran X as root".
• There is no least privilege. Somebody who needs to restart a service does not need to be able to read /etc/shadow or reformat a disk.

That is why Ubuntu ships with root having no usable password (! in shadow, as you saw in 05-01) and all administrative work goes through sudo.

The dash in su - (and in -i) is what makes the difference: without it you carry your variables, your aliases and your PATH into a session with UID 0, and that is exactly the vector by which a tampered PATH with a fake ls ends up running as root. If you need a root session, use sudo -i. And as a general rule, neither of the two: one sudo per action leaves a better trail than a root session left open for half an hour.

What sudo does when you invoke it: it checks your identity against /etc/sudoers, asks for your password (not root's), logs the order, builds a fresh environment and runs the command with the target identity.

The credential cache remembers that you already authenticated for 15 minutes per terminal (timestamp_timeout, in minutes; 0 disables it and -1 makes it eternal, which is a bad idea). sudo -k invalidates it right now, sudo -v renews it without running anything, which is useful at the start of a long script.

Options used every day:

By default env_reset wipes your environment and secure_path imposes a fixed PATH. It is a deliberate protection: without it, exporting LD_PRELOAD or altering the PATH before a sudo would be an immediate promotion to root. That is also why sudo sometimes cannot find one of your binaries in /home/operator/bin: it is not in secure_path, and you have to give the absolute path.

And the classic we have been carrying since Module 3:

It is not echo that fails: the redirection fails, and your shell — which is still operator — does it before sudo even gets to run. The two correct solutions:

The file is /etc/sudoers, but you do not edit it: you edit it with visudo, and your own rules go in separate files inside /etc/sudoers.d/, which sudoers pulls in with @includedir. visudo locks the file against simultaneous edits and, above all, validates the syntax before saving. A sudoers with a syntax error leaves the system without any working sudo, and that is an emergency.

The files in /etc/sudoers.d/ must have mode 0440, ownership root:root, and contain no dot and not end in ~ in the name, or sudo silently ignores them.

• A % in front of the name means group: that is why belonging to sudo gives you powers, it is this line.
• machine lets you distribute the same sudoers across a whole fleet; on a standalone server you write ALL.
• (root) is the target identity; (ALL:ALL) additionally lets you choose a group with -g.
• NOPASSWD: avoids asking for the password. Convenient for what a script runs; dangerous for everything else.

sudoers accepts ! to deny, and it is a trap:

It can be bypassed in a thousand ways. If you can run ALL, you can run cp /bin/bash /tmp/sh && chmod u+s /tmp/sh, or simply:

The golden rule: a sudo rule is a whitelist. Enumerate what is allowed; do not try to enumerate what is forbidden. And be suspicious of any command that knows how to run other commands or edit arbitrary files (vim, less, find, awk, tar --to-command, systemctl without a fixed subcommand, any interpreter).

Safe rules:

The same information is in the journal (journalctl -t sudo, which we will see in 05-06). Failed attempts are logged just the same, and they are the cheapest alarm signal a server has.

If you need more, sudoers can record the entire session with Defaults!SERVICE log_input, log_output and Defaults iolog_dir=/var/log/sudo-io; it is played back with sudoreplay -l and sudoreplay ID. Careful: it records what is typed, including passwords typed by mistake, so that directory is sensitive material and its retention must be agreed.

If you saved an invalid sudoers without visudo, any sudo answers with something like >>> /etc/sudoers: syntax error near line 22 <<< and refuses to work. Ways out, in order of preference:

1. A root session still open in another terminal: fix it from there. That is why it pays to have one open while you touch these files.
2. pkexec, which uses polkit and does not depend on sudoers: pkexec visudo (it requires a polkit rule to exist for your user, which is usual on desktop installations).
3. Recovery mode: reboot, choose Advanced options → recovery mode → root shell, remount with mount -o remount,rw / and run visudo. The full procedure is the subject of 07-01.

The habit that avoids all of this: always edit with visudo, and before you close the session, check in another terminal that sudo -l still works.

Every process carries two identities: the real UID (who launched it) and the effective UID (the one permissions are checked against). Normally they match. The SUID bit breaks that equality: when a binary with SUID is executed, the kernel sets the effective UID to that of the file's owner, not that of whoever runs it.

The canonical example is passwd, which has to write to /etc/shadow (640 root:shadow) while being invoked by an ordinary user:

That s in place of the owner's x is SUID. While it runs, passwd is root, and its code is written to do exactly one thing and nothing else.

A SUID root binary of your own is almost always a security flaw, because any slip inside the program — a call to system(), an inherited PATH, an overflow — turns into root for whoever invokes it. A shell script with SUID does not even work: Linux ignores the bit on interpreters, precisely because it is impossible to secure.

A mandatory audit on any server:

Keep that list as a baseline. Any binary that appears afterwards and does not come from a package is an alarm. -perm -2000 does the same for SGID.

On an executable, SGID is the group's equivalent of SUID. But its important use is another one: on a directory, SGID makes everything created inside inherit the directory's group instead of the primary group of whoever creates it. It is the piece that makes shared work viable.

Without SGID, if operator (whose primary group is operator) leaves a backup in /srv/tramontana/backups, the file belongs to the operator group and luis cannot read it even though they are both in tramontana. With SGID:

The tramontana group without having asked for it: that is SGID. Apply it to the whole shared tree and not just to the root:

The SGID bit does not fix the permissions: if your umask is 027, the file comes out rw-r----- and the group can only read. For the group to write as well you need umask 007, or better, a default ACL (section 11).

/tmp is writable by everybody. Without extra protection, anybody could delete somebody else's temporary file, because the permission to delete depends on the directory, not on the file. The sticky bit corrects that: in a directory with sticky set, only the file's owner, the directory's owner and root can delete or rename it.

That final t is the sticky bit (octal 1). It is the reason why the mktemp in your Module 4 scripts is safe from the neighbour, even though it still needs a trap to clean up.

A summary of the three bits:

A capital S or T in ls -l means the special bit is set but the corresponding x is missing: nearly always a typo.

SUID is all or nothing: you hand over the whole of root to obtain a single faculty. Linux capabilities split root's privileges into about forty independent pieces, and they can be granted one at a time.

The textbook case: Tramontana wants to listen on port 80, and ports below 1024 require privilege. Instead of running the application as root:

e is effective and p is permitted. Now the binary opens port 80 as svc-tramontana and cannot do anything else that root could. Other common ones: cap_net_raw (for a ping of your own), cap_dac_read_search (read any file: almost as dangerous as root, be careful), cap_sys_time.

Real warnings: capabilities are an extended attribute of the file, so they are lost when you copy it, when you replace the binary in a deployment and on a filesystem that does not support them. If deploy.sh replaces the release, they have to be applied again — or, better, let systemd do it with AmbientCapabilities in the unit, which is what we will build in 05-05.

The classic model has three subjects: owner, group, others. Marta asks for something that does not fit there: "let Luis read /var/log/tramontana for diagnostics, but without putting him in adm, which gives access to every log on the system". With ugo you could only change the directory's group or open it up to "others". With ACLs, you give exactly that permission to that person.

We grant read and traverse to luis, and make anything created afterwards inherit it:

That + at the end of the permissions is the mark that an ACL exists; without it, ls -l would be lying to you by omission.

The mask (mask::) is the ceiling of effective permissions for every entry except user:: and other::. If the mask is r--, an entry of user:luis:rw- is effectively left at r--, and getfacl flags it with an #effective:r-- comment. And here is the trap: chmod g=... rewrites the mask, so a later chmod -R 750 can silently cancel all your ACLs. If you use ACLs, review them after any chmod on that path.

A requirement: the filesystem must be mounted with ACL support, which on Ubuntu 24.04's ext4 is enabled out of the box. And do not forget that cp does not copy ACLs unless you use -p or -a, nor does tar unless you use --acls.

Underneath the permissions there is one more layer: the filesystem attributes. The useful one for an administrator is i, immutable: the file cannot be modified, deleted, renamed or linked, not even by root, until the attribute is removed.

It is a safety net against human error and against overenthusiastic scripts, not against an attacker with root (who can remove it just as you can). Another useful attribute is a (append-only), designed for log files: you can append, but not rewrite or truncate. And a practical warning: an immutable file breaks any automation that touches it, including apt and your own deploy.sh. Write it down in the HISTORY or you will pay for it at 4:20 in the morning.

Marta approves the deployments, but the person who runs them is operator, who today has full sudo by virtue of being in the sudo group. The goal: let them do their job — manage the service and deploy — without total root, and let luis check the status without touching anything.

Details that are not decorative:

• deploy-safe is a wrapper owned by root:root with mode 0755 in /home/operator/bin/. If it belonged to operator and were writable by them, the rule would be equivalent to handing over full root: they could rewrite the script with /bin/bash inside. This is the most frequent flaw when granting "just one script".
• The subcommands are fixed: plain systemctl would allow systemctl edit, and from there to an editor as root is a single step.
• luis has read-only access and with NOPASSWD, because he calls it from his diagnostics panel. operator remains in the sudo group for as long as the transition lasts; the medium-term goal is to take them out and keep only these rules.

Compliance warning. A sudo rule is a grant of privilege with a direct impact on the system's security and on access to guests' personal data (the logs and the backups contain it). Every addition, change or withdrawal of rules must be documented, with a date and the person who authorised it, and it must be reviewed by the security or compliance officer (GDPR) before being applied in production. Review sudo -l -U user for each account at least once a quarter and at every staff departure.

And the pieces from the previous sections applied to the project:

• Editing /etc/sudoers with a normal editor. One syntax error and you are locked out: always visudo, and keep a second terminal open while you edit.
• A badly named file or one with the wrong permissions. sudo silently ignores files in /etc/sudoers.d/ that contain a dot or are not 0440. Check with sudo -l -U user.
• Granting a script the user can edit. It is full root in disguise. The target of a rule must be root:root and not writable by its beneficiary.
• Using wildcards or commands "that run things". systemctl, vim, less, find, tar, any interpreter: all of them have a known route to a shell. Fix the subcommand and the arguments, and do not rely on ! to deny: blacklists are always bypassed.
• Applying SGID only to the top folder of a shared tree: the existing subdirectories do not inherit it; use find -type d -exec chmod g+s {} +.
• Losing the capabilities in a deployment. setcap lives in the file; if you replace the binary, it disappears. Declare it in the systemd unit.
• A chmod that wipes out the ACLs by rewriting the mask: after any chmod on a path with a +, verify with getfacl.
• Tip: keep the baseline of find / -perm -4000 and of getcap -r / next to the HISTORY. Comparing that list is the cheapest and most effective audit you can carry out.

1. A minimal, correct rule. The intern must be able to restart only tramontana.service and see its status, with no password for the status and with a password for the restart. Write the file, install it with the right permissions, validate it and demonstrate that sudo systemctl restart nginx is forbidden to them.
2. A SUID audit. Find the system's SUID binaries, check which package each one belongs to and explain why finding /usr/local/bin/util with SUID root would be an alarm.
3. A write ACL for a third party. Marta needs to drop a rates file into /srv/tramontana/backups/outgoing/ without belonging to the tramontana group. Grant her write access only in that subdirectory, with inheritance, and verify the effective mask.

1.

When trying what is forbidden, as intern:

Note that the list is a whitelist: we have not written a single prohibition, and everything not enumerated is left out by construction.

2.

/usr/local/bin/util does not belong to any package: nobody in the distribution vouches for it, it is not updated by apt and nobody has audited its code. With SUID root, any flaw in it — or any system() that inherits the PATH of whoever invokes it — hands root to any user on the system. A binary like that on a production server is investigated as a possible compromise, it is not "left there just in case".

3.

u:marta:rwx on the directory lets her enter and create; the default: entry makes the files she leaves inside be born with rw- for her. The mask is rwx, so the effective permissions are the ones granted: if it were r-x, getfacl would flag #effective:r-x and Marta could not write despite the entry. And remember: a later chmod g=rx on that directory would rewrite the mask and cancel the permission without touching Marta's entry.

The magic of sudo is over, and so is that of the s you had been carrying since 02-07. You know that root does not have permissions but rather an absence of checks, and why that forces you to work with least privilege and traceability; you tell su from su - and sudo -s from sudo -i by the environment each one inherits; you understand env_reset, secure_path and why the redirection in sudo echo fails; you write sudoers rules with visudo, in /etc/sudoers.d/, with absolute paths, fixed arguments and in whitelist form, knowing that blacklists are bypassed from vim, find or awk; you know where the trace is left and how to get out of a broken sudoers.

And you have mastered the permission layer the ugo model does not cover: SUID and the difference between the real and the effective UID, with find -perm -4000 as an audit; SGID on directories so that a team really shares files, already applied to /opt/tramontana/shared/uploads and to /srv/tramontana/backups; the sticky bit that makes /tmp safe; the capabilities that replace an entire SUID with a single faculty such as cap_net_bind_service; the ACLs with which Luis reads /var/log/tramontana without joining adm, with their mask and their chmod trap; and chattr +i to armour /etc/tramontana/app.conf. In /etc/sudoers.d/tramontana there is a real, validated, documented rule that lets the service be operated without handing out root.

The next loose end is the software. You have been installing things with apt for four modules without asking where they came from, who signs them or what happens if the database engine jumps a major version one night while you sleep. In Package Management you will see Debian's two layers, dpkg and apt, the anatomy of a .deb, Ubuntu 24.04's deb822-format repositories with their keys in /etc/apt/keyrings/, how to pin versions so that Tramontana's database does not move on its own, and the uncomfortable debate about whether a server should reboot itself after a security update.