Vier Entscheidungen aus dem Struktur-Workshop. Kadenz: Refinement sonntagabends, woechentlich. Sonntag, weil die GitLab-Backups dort ohnehin laufen und die Woche an der Stelle eine Kante hat. Die Retro light bekommt bewusst KEINEN eigenen Termin, sondern haengt am ersten Refinement des Monats - ein monatlicher Extra-Termin im Solo-Betrieb ist ein Termin, der ausfaellt. Board-Pflege bei Abwesenheit: Eine Session darf abbilden, aber nicht zusagen. Erlaubt sind status:wartet, Schliessen, Fristen nachtragen, Issues anlegen; nicht erlaubt sind status:doing und status:next. Die Trennlinie ist nicht Vorsicht, sondern Bedeutung - doing und next sagen, was als Naechstes wirklich passiert, und das entscheidet sorb. Jede Aenderung wird im Issue begruendet. ADR-0008 zu #14: Agenten-Sessions auf CFGMON laufen root-aequivalent ueber die docker-Gruppe, und das bleibt so - ausdruecklich. Damit gilt 'sudo mit Passwort' auf diesem Host nicht als Kontrollmechanismus. Option B haette das Auditproblem geloest, indem sie den Arbeitsweg entfernt (sudo braucht ein TTY, das eine Session nicht hat); Option C bleibt Ziel, lohnt aber erst bei einem zweiten Menschen - ihr Nutzen ist Zuordnung, und im Ein-Personen-Betrieb gibt es niemanden, gegen den sie schuetzen wuerde. Als ADR und nicht als Absatz in hosts/cfgmon.md, weil eine Ausnahme nur zu dokumentieren statt sie zu entscheiden genau der Fehler ist, den die ADR-Pflicht adressiert. Die im Issue geforderte Vorklaerung - welche Konten sonst in der docker-Gruppe sind, gilt dasselbe auf MATRIX - ist ausdruecklich als offen vermerkt statt stillschweigend uebergangen. Definition of Done: Baustein 4 der Textbausteine IST die kurze DoD fuer Aenderungen ohne Deploy, statt eines eigenen Dokuments. Ein drittes Dokument waere die dritte Fassung derselben Regeln und damit die dritte, die driftet. 62 relative Links geprueft, keiner tot. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01PKhFj1S3UdD6xL2fbWPeYj
4.3 KiB
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.