SQLite Data Studio: Berechtigungen

Zurück: SQLite Data Studio

[Live] Feingranulares, serverseitig erzwungenes Berechtigungsmodell — bildet DokuWiki-Gruppen/Benutzer auf Studio-Fähigkeiten ab. Kein Ersatz für die Seiten-ACL: die Policy regelt ausschließlich Studio-Funktionen, nie den Lesezugriff auf Wiki-Seiten.

Fähigkeiten-Modell

Fähigkeit	Erlaubt
`use`	Routinen über den Service ausführen bzw. im Studio testen
`query`	SQL-Konsole lesend, Tabellen-/View-Struktur ansehen
`write`	DML: Browse-Edit, Konsole schreibend
`design`	DDL: Table Designer, Löschen von Tabellen/Views/Indizes/Fremdschlüsseln
`export`	Ergebnis-/Tabellenexporte
`admin`	Verbindungen, Routinen-Verwaltung und die Berechtigungs-Matrix selbst verwalten

Auflösungsreihenfolge

Bei jeder Prüfung PolicyGate::isAllowed($capability, $conn, …) gilt, in dieser Reihenfolge, die erste zutreffende Regel:

Superuser-Bypass — immer erlaubt, unabhängig von jeder Matrix-Regel (auch bei einer unbekannten/tippfehlerhaften Fähigkeitsanfrage wird zuerst geprüft, ob die Fähigkeit überhaupt existiert — ein Programmierfehler mit erfundenem Fähigkeitsnamen darf nicht einmal für einen Superuser versehentlich „erlauben„ liefern).
dbadmin_readonly=1 übersteuert write/design immer auf verboten, selbst wenn die Matrix sie erlauben würde — nie umgangen durch die folgenden Regeln.
Verbindungs-scope-Regel schlägt global; innerhalb eines Scopes schlägt eine Regel für den exakten Benutzernamen jede @gruppe-Regel — mehrere zutreffende Gruppenregeln desselben Scopes werden vereinigt, wenn keine benutzerspezifische Regel existiert.
Sonst Default-Deny.

Matrix-Dialog

„Berechtigungen…“ im Command-Bar der Bereiche Verbindungen/Übersicht bzw. in der rechten Modul-Rail öffnet den Matrix-Dialog: Zeilen sind Gruppen/Benutzer in acl.auth.php-Notation (führendes @ = Gruppe), Spalten die sechs Fähigkeiten, ein Geltungsbereichs-Umschalter (global ↔ je Verbindung).

Geerbt vs. eigene Regel: im Geltungsbereich einer Verbindung zeigt eine Zeile ohne eigene Verbindungsregel den geerbten globalen Wert (gedimmt, Badge „geerbt„); eine eigene Verbindungsregel ersetzt den globalen Wert für dieses Subjekt vollständig (keine Vereinigung von global + eigen).
Zeile entfernen läuft über denselben Zwei-Schritt-Bestätigungsdialog wie jede andere destruktive Studio-Aktion — das Entfernen einer Regel kann unmittelbar ändern, was ein Nutzer darf.
Persistenz: conf/wksqliteds.policy.json, atomarer Schreibvorgang + .bak, keine Secrets enthalten.
Ein fehlerhaftes/kaputtes policy.json fällt geschlossen auf die leere Matrix zurück (Default-Deny für alle außer Superuser) statt einen Fehler zu werfen oder teilweise vertraute Daten zu übernehmen.

Zweistufigkeit

Stufe 1 (abgeschlossen): Default-Policy „nur Superuser“ — verhaltensneutral zur vorherigen Welt; Matrix-UI und Gate waren produktiv, änderten aber effektiv nichts, solange niemand die Policy erweiterte.
Stufe 2 (abgeschlossen, nach dokumentiertem Security-Review): das Studio-Menü und jeder Bereichs-Einstieg sind an die Policy gekoppelt — ein Nicht-Superuser mit mindestens einer Fähigkeit sieht das Studio-Menü und kann exakt das, was seine Matrix-Einträge erlauben; ein Deep-Link auf einen verbotenen Bereich zeigt eine neutrale Ablehnungsseite ohne interne Details (keine genannte Fähigkeit, kein Verbindungsname). Sichtbarkeitsfilterung wirkt auf Bereichs-/Tab-Ebene (Verbindungen/Datenbank/Routinen) — nicht auf einzelne Schaltflächen innerhalb eines Bereichs, da das serverseitige Gate jede tatsächliche Mutation ohnehin vollständig verhindert (UI-Sichtbarkeit ist nie die alleinige Absicherung).

Grenzfälle

Inline-PHP in Routinen bleibt unabhängig von jeder Matrix-Erlaubnis an echte Superuser gebunden (auch mit design/use gewährt) — Details: Routinen → Inline-PHP-Bedrohungsmodell.
Auxbar-AJAX-Endpunkt verlangt die Fähigkeit query zusätzlich zu Login/sectok/ACL-Prüfung — dieselbe Reihenfolge (additiv, nie ersetzend) gilt für jeden Dispatch-Punkt.
Login-/Gruppenwechsel wirken sofort: die Auflösung liest Benutzername/Gruppen bei jedem Request neu, es gibt kein über Logins hinweg zwischengespeichertes Ergebnis.
Abgelehnte Zugriffsversuche werden protokolliert (Nutzer + angefragte Fähigkeit + Verbindung, nie Abfrageinhalte) — bewusst auf debug-Log-Ebene, um bei aktivierter Log-Unterdrückung (exFAT-Betrieb) nicht zusätzlich zu belasten.

Zweiter Faktor: die Frage, die diese Matrix nicht beantwortet

[Live seit 2026-08-09] Die Matrix oben beantwortet wer bist du, und zwar aus der Sitzung. Sie beantwortet nicht bist du es gerade noch. Eine übernommene Sitzung — gestohlener Keks, unbeaufsichtigter Arbeitsplatz — hat in diesem Bildschirm dieselben Rechte wie der Kontoinhaber.

Für die drei Fähigkeiten mit der größten Reichweite verlangt das Studio deshalb zusätzlich einen in dieser Sitzung kürzlich nachgewiesenen zweiten Faktor. Der Nachweis läuft über den Identity Plugin Contract v1 (Vertragsbeschreibung) und ist rein additiv: er ersetzt weder die Seiten-ACL noch die Matrix, sondern kommt als drittes Tor dazu.

Die drei Kategorien

Kategorie	Anforderung	Warum sie eine ist
`code-write`	`MFA_ANY`	Eine Routine ist SQL-Text, den der Ausführer später ausführt — wer sie schreiben darf, hinterlegt ausführbaren Code in der Installation
`connection-admin`	`MFA_ANY`	Eine Verbindung trägt Zugangsdaten zu fremden Datenbanken
`db-destructive`	`MFA_ANY`	Verwerfen, Löschen, Einspielen und Wiederherstellen — Datenverlust ohne Weg zurück

Vierzehn Aktionen fallen darunter: routine_create, routine_save, routine_save_props, routine_delete · conn_create, conn_save, conn_delete · db_table_drop, db_view_drop, db_rows_delete, db_import_run, db_restore_run, db_optimize, db_backup_delete.

Was ausdrücklich keinen zweiten Faktor verlangt

Jede lesende Aktion — routine_test, conn_test, db_export, db_sql_run, db_check_syntax, db_integrity_check und jede Vorschau. Sie ändern nichts.
Einzelzeilen-Bearbeitung und die Berechtigungsmatrix selbst. Das ist die tägliche Arbeit dieses Bildschirms.

Der Grund ist keine Bequemlichkeit: eine Werkbank, die vor jeder Abfrage einen Code verlangt, wird abgeschaltet statt benutzt — und ein Faktor, der ständig verlangt wird, wird zur Formsache und schützt dann nichts mehr.

Wo geprüft wird, und warum an zwei Stellen verschieden

Abgesendete Aktionen prüft admin.php::handle(), vor der Verzweigung. Action\Admin::preProcess() ruft handle() vor jeder Ausgabe — die Weiterleitung in die Aufforderung ist dort möglich.
Der Renderpfad kann das nicht: er läuft mitten in der Seite, und eine Weiterleitung von dort scheitert still. Dafür gibt es die Brücke do=wksqliteds_stepup, eine eigene Anfrage, die vor jeder Ausgabe entscheidet.

Die Brücke nimmt nie eine Anforderung entgegen, nur einen Namen. category wird gegen die fest verdrahtete Liste oben geprüft, bevor irgendetwas damit geschieht; ein unbekannter Name ergibt eine Ablehnung, niemals „keine Anforderung„. Und das Rücksprungziel wird über den Vertrag aufgelöst, nie aus der Anfrage übernommen.

Die Aktionstabelle steht genau einmal, in StepUpBridge; admin.php liest sie über categoryForAction(). Dieses Paket hat für eine Tabelle, die von ihrem eigenen Verteiler abgedriftet ist, bereits dreimal bezahlt — der Testsatz sichert beide Richtungen gegeneinander ab.

Ohne wkidentity ändert sich nichts

Ist das Identitätspaket nicht installiert, lautet die Antwort erlaubt, und der Bildschirm verhält sich exakt wie vorher. Das ist ein gewolltes Fail-open: der Vertrag ist additiv zur Zugriffsliste, und ein fehlendes Zusatzpaket darf keinen Bildschirm sperren, der vorher lief.

Ein Konto mit installiertem Paket, aber ohne eingeschriebenen Faktor bekommt die Meldung stepup_denied. Sie nennt, was fehlt, statt „weise es jetzt nach“ zu sagen: wer die Anforderung erfüllen könnte, wird in eine echte Aufforderung umgeleitet und erreicht diese Meldung nie.