Thore CimbalandClaude Fable 5
70e81e2ff1
Gate 4, slice 2: decisions/0001-0011 moved via git mv with schema frontmatter prepended (status and date taken from each body's own Status line - 0007 stays proposed, its decision is open in #20; bodies unchanged except relative links gaining one directory level). The old scheme's README and template retire - their rules already live in AGENTS.md section 6 and the neckbeard ADR template. Every reference to decisions/ across the tree retargeted (root files, not-yet-moved verfahren/hosts/shared files, design doc and session ADR frontmatter). Verified: validate 0 errors (11 ported + 2 session ADRs + duplicate-id guard), gen_status --check current with all 13 ADRs listed, drift check 0 findings, negative test shows a cloned id 0012 firing the duplicate check. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
4.4 KiB
type, id, status, date, supersedes, superseded_by, related
| type | id | status | date | supersedes | superseded_by | related |
|---|---|---|---|---|---|---|
| adr | 0008 | accepted | 2026-08-06 | null | null |
0008 — Agenten-Sessions auf CFGMON laufen root-äquivalent über die docker-Gruppe
Status: akzeptiert · Datum: 2026-08-06 (Struktur-Workshop #17) · Entscheider: sorb
Kontext
sudo ist aus einer Agenten-Session nicht bedienbar: Es gibt kein TTY, also auch
keine Passworteingabe („a terminal is required to read the password"). Die
LABNET-02-Nacht lief deshalb über die docker-Gruppenmitgliedschaft des Kontos
rantanplan — privilegierter Container plus nsenter in die Host-Namespaces.
Das ist root-äquivalent, und zwar ohne Umweg: Wer Docker steuern darf, darf alles. Auf Linux ist das normales Verhalten der docker-Gruppe und kein Konfigurationsfehler — aber es hat zwei Folgen, die benannt gehören:
- Die sudo-Passwortabfrage ist für dieses Konto keine Sicherheitsgrenze. Sie sieht aus wie eine, ist aber umgehbar, ohne dass jemand etwas umgehen wollte.
- Dieser Weg hinterlässt keinen Eintrag in
auth.log. Was über die docker-Gruppe geschieht, ist im Nachhinein nicht aus den üblichen Protokollen rekonstruierbar.
Aufgedeckt im CFGMON-AAR (Befund 3, MEDIUM), erfasst als #14.
Entscheidung
Es bleibt so — ausdrücklich und dokumentiert. Agenten-Sessions auf CFGMON arbeiten root-äquivalent über die docker-Gruppe.
Daraus folgt unmittelbar: Auf diesem Host gilt „sudo mit Passwort" nicht als Kontrollmechanismus. Wer dort Sicherheit gegen unbeabsichtigte oder unerwünschte Änderungen braucht, muss sie woanders aufhängen — an der Erreichbarkeit des Hosts, an der Vergabe der Zugangsdaten, an der Frage, wer überhaupt eine Session starten kann.
Ziel bleibt Option C (eigenes Agenten-Konto mit definierter, protokollierter Rechteerhöhung), aber erst wenn ein zweiter Mensch mitarbeitet. Der Nutzen von C ist Zuordnung — nachvollziehen zu können, wer was getan hat. Im Ein-Personen-Betrieb gibt es niemanden, gegen den diese Zuordnung schützen würde; sie wäre Aufwand ohne Adressaten.
Konsequenzen
- Der Arbeitsweg bleibt funktionsfähig. Host-Sessions können weiterarbeiten; ohne diese Entscheidung wäre LABNET-02 gar nicht durchführbar gewesen.
- Die Protokollierung fehlt und wird nicht ersetzt. Wer im Nachhinein wissen
will, was eine Session auf CFGMON getan hat, findet es nicht in
auth.log, sondern nur in Git-Historie, Issues und AARs. Das ist der Grund, warum die AAR-Pflicht und „alles Offene wird ein Issue" auf diesem Host besonders zählen — sie sind hier der einzige Nachvollzug. - Ein kompromittiertes
rantanplan-Konto ist ein kompromittierter Host. Nicht neu durch diese Entscheidung, aber jetzt ausgesprochen. - Auslöser für Option C ist ein zweiter Mensch mit Zugang — nicht ein Datum. Kommt einer dazu, wird diese ADR abgelöst.
Offen, bewusst nicht vor der Entscheidung geklärt
Das Issue verlangte vorab zu klären, welche anderen Konten in der docker-Gruppe sind und ob dasselbe auf MATRIX gilt. Beides ist ungeprüft — dafür braucht es eine Host-Session, vom Mac aus ist es nicht einsehbar.
Das ändert an der Entscheidung nichts (sie betrifft den Weg, nicht seinen Umfang), wohl aber an ihrer Reichweite: Sollte sich zeigen, dass weitere Konten in der Gruppe sind, ist zu prüfen, ob die alle dort hingehören. Nachzuholen bei der nächsten Host-Session, festgehalten in #14.
Verworfene Alternativen
- B — Konto aus der docker-Gruppe nehmen, Docker-Zugriff über gezielte
sudo-Regeln. Auditierbar, aber es legt Agenten-Sessions auf CFGMON lahm:
sudobraucht ein TTY, das eine Session nicht hat. Löst ein Protokollproblem, indem es den Arbeitsweg entfernt — vertretbar erst, wenn ein Ersatz steht. - C sofort — getrenntes Agenten-Konto mit protokollierter Rechteerhöhung. Sauberste Lösung, aber echte Arbeit für einen Nutzen, der im Ein-Personen-Betrieb nicht anfällt. Bleibt das Ziel, siehe oben.
- Stillschweigend so lassen. Genau das ist der Fehler, den ADR-0002 und die
ADR-Pflicht für dauerhafte Ausnahmen adressieren: Eine Ausnahme nur zu
dokumentieren statt sie zu entscheiden, ist keine Entscheidung. Deshalb diese ADR
und nicht bloß ein Absatz in
hosts/cfgmon.md.