Die Attrappe des Supabase-Schemas gibt der Anwendungsrolle mit Absicht
kein usage auf `auth`: "fiele je wieder ein Bezug auf dieses Schema in
den laufenden Betrieb, soll er scheitern und nicht stillschweigend
funktionieren." Er ist gefallen, und sie scheitern.
Auf dem Server nachgemessen, nicht vermutet:
select has_schema_privilege('alpenwerk_app', 'auth', 'usage'); -- f
set local role alpenwerk_app; select auth.uid();
-- ERROR: permission denied for schema auth
Keine der acht ist security definer, sie laufen also mit den Rechten der
Anwendungsrolle. Betroffen war je eine vollstaendige Operation:
Versetzung, Planstelle anlegen, Planstelle loeschen, Angehoerige
hinzufuegen und entfernen, HR-Notiz anlegen und erledigen, Rueckkehrdatum
verschieben.
Der Umstieg auf app_current_user_id() geschah im August und danach
Funktion fuer Funktion, sobald eine ohnehin angefasst wurde. Diese acht
wurden seither nicht mehr angefasst, und nichts prueft den Rest: die
Migrationen laufen durch, die Tests kennen keine Datenbank, und wer die
Oberflaeche bedient, bekommt die Meldung erst beim Speichern.
Geaendert ist nur zweierlei je Funktion -- auth.uid() wird
app_current_user_id(), und der search_path steht fest. Die Koerper sind
unveraendert aus ihren letzten gueltigen Fassungen uebernommen.
Die Selbstpruefung geht das ganze Schema durch statt nur die acht: sie
schlaegt an, sobald irgendeine Funktion in public das Schema auth wieder
anfasst, und prueft zusaetzlich, dass das Recht entzogen bleibt.
Andrei Laas
01c49ee56c