2.5 KiB
2.5 KiB
status, initiated, touches, became
| status | initiated | touches | became | ||||||
|---|---|---|---|---|---|---|---|---|---|
| active | 2026-10-04 |
|
027 — The system layer as modules
What is investigated
What runs on the machines below the operator's home and outside the mesh's own services, and which of it should be modules. That covers:
- the container runtime and its tools;
- privilege (sudo);
- the package manager and the software it cannot install;
- time, locale, the kernel and boot;
- log rotation;
- the machine-specific daemons the workstations and servers carry: printing, bluetooth, VPN clients, virtualisation, storage, sharing.
Why
The operator asked for the system level beside the graphical session. In particular:
- a
dockermodule (decided in principle by the proposed ADRs 0165 and 0166, never built); - a
docker-composemodule for development work, assigned only to the two workstations.
Measured in 01: on four machines, almost nothing at this level is owned by a module. The pieces differ by machine for no recorded reason. Three findings are security matters on their own.
What it touches
- The container runtime seat (ADRs 0165 and 0166, both proposed).
- The host's
packageshape, which installs from the distribution's official repositories only, while the workstations carry 67 and 114 packages from elsewhere. - How a secret reaches the account's environment. ADR 0203 forbids it in the contributed environment, but a predecessor file supplies such secrets today.
- The facts the mesh assumes and never declares, above all that the operator account escalates without a prompt.
Documents
- 01 — What the machines run: evidence.
- 02 — Candidates and questions
- 03 — The account's own tools:
~/.sshas one module's, scripts on every machine, the keyring, mail as events - The predecessor's lessons, shared with research 026: 026/03