Verstecken von Sourcecode in der DB

Themen rund um den praktischen Einsatz von Firebird. Fragen zu SQL, Performance, Datenbankstrukturen, etc.

Moderator: thorben.braun

Antworten
zappa2
Beiträge: 19
Registriert: Fr 5. Okt 2018, 10:59

Bis einschl. FB 2.5 konnte man seinen Quellcode von StoredProcs und Triggern verstecken, indem man den Text in den Systemtabellen entweder gelöscht oder geändert hat:

Code: Alles auswählen

UPDATE RDB$TRIGGERS SET RDB$TRIGGER_SOURCE = NULL
WHERE RDB$SYSTEM_FLAG IS NULL OR RDB$SYSTEM_FLAG=0;

UPDATE RDB$PROCEDURES SET RDB$PROCEDURE_SOURCE = NULL
WHERE RDB$SYSTEM_FLAG IS NULL OR RDB$SYSTEM_FLAG=0;
Da die BLR unverändert bleibt, arbeiten Trigger und SPs normal weiter, sind aber natürlich nicht mehr editierbar. Also evtl. nicht wirklich für die Entwicklungs-DB zu empfehlen.
Seit 3.0 geht das nun aber nicht mehr, ist ein Update auf RDB$-Tabellen verboten.

Ist das ein Bug oder ein Feature? Oder gibt es ein Workaround dazu?
bfuerchau
Beiträge: 276
Registriert: Mo 7. Mai 2018, 18:09

Ich denke mal, das liegt nur an den Berechtigungen für die Tabellen.
Prozeduren/Funktionen sind ja separate Objekte die berechtigt werden können.
Die Definitin in den Tabellen müssen halt nicht allen Usern zugänglich sein.

Klar ist, wenn ich die DB mitnehme und dann als Admin wieder reinschaue, kann ich
halt sehen, was das so getrieben wird.
Das ist aber ein generelles Problem aller Datenbanken.

Je nach Anforderungen arbeite ich kaum bis gar nicht mit Prozeduren sondern regele alle im Client oder Service. Für bestimmte notwendige Sachen verwende ich dann halt Execute Block.
vr2
Beiträge: 102
Registriert: Fr 13. Apr 2018, 00:13

zappa2 hat geschrieben: Mi 9. Dez 2020, 11:02 Seit 3.0 geht das nun aber nicht mehr, ist ein Update auf RDB$-Tabellen verboten.

Ist das ein Bug oder ein Feature? Oder gibt es ein Workaround dazu?
Ein Feature. Direkte Änderung von Systemtabellen ist seit Firebird 3 nicht mehr möglich, Sicherheit, Konsistenz, ....
Ein Argument gegen das Leeren des SP-Codes ist, dass auch aus der BLR der SP-Code relativ einfach (ohne Kommentare) rekonstruiert werden kann.

Der offizielle Weg seit Firebird 3 ist, die Datenbank zu verschlüsseln, dazu gibt es seit der Version eine Schnittstelle für crypt-Plugins. Dieser Weg ist aber nicht ganz einfach, man braucht bspw außerdem eine modifizierte gbak, und man verliert grob 5% Performance. Weitere Links:

Analyse: Warum die Datenbank überhaupt verschlüsseln?
https://www.firebirdsql.org/file/docume ... urity.html

Firebird-Verschlüsselung
https://www.firebirdsql.org/file/docume ... ption.html

Kommerzielle Pakete dafür
https://ib-aid.com/en/firebird-encrypti ... framework/
https://www.ibexpert.net/ibe/pmwiki.php ... nPluginFB3

Grüße, Volker
Benutzeravatar
martin.koeditz
Beiträge: 283
Registriert: Sa 31. Mär 2018, 14:35

Hallo zusammen,

zu diesem Thema schwirrte mir noch etwas im Hinterkopf. Grundsätzlich darf nicht mehr in die Systemtabellen geschrieben werden. Da das Löschen von Quellcodes in Prozeduren und Triggern vielen Anwendern wichtig war, wurde diese Funktion explizit erlaubt.

Siehe auch http://tracker.firebirdsql.org/browse/CORE-4507

Das heißt, diese Anweisung funktioniert:

Code: Alles auswählen

UPDATE
      RDB$PROCEDURES P
SET
   P.RDB$PROCEDURE_SOURCE = NULL
WHERE
     P.RDB$SYSTEM_FLAG = 0;
Ist der Source-Code bereits auf NULL gesetzt, erscheint eine Fehlermeldung.

Gruß
Martin
Martin Köditz
it & synergy GmbH
Antworten