[solved] Proxy-DLL für SQLServer-Statements Kontrolle
-
Hi,
wir haben für mehrere Softwarelösungen Proxy-DLLs erstellt, die (schon bestehende) Clientsoftware bei der Verbindung mit Oracle-Datenbankservern überwacht und bestimmte SQL-Statements nicht ausführt, wenn sie nicht erlaubt sind (kein Zugriff auf Tabelle, kein Zugriff auf bestimmte Columns usw).
Das selbe wollten wir nun für SQLServer machen, dort müssen wir "TOAD for SQLServer" als Hauptclient einsetzen. Jedoch ist diese Version von TOAD, im Gegensatz zu "TOAD for Oracle", in C# geschrieben, d.h eine einfache Proxy-DLL scheint man hier nicht implementieren zu können.
Die alte Vorgehensweise war, mittels eines Skriptes und "dumpbin /exports" eine Proxy-DLL zu generieren, die am Anfang erst einmal stupide alle Anfragen an die originale DLL weiterleitet.
Sowas wollten wir nun auch für SQLServer machen, und haben Proxy-DLLs für sqlsrv32.dll und odbc32.dll gebastelt. Jedoch ruft "TOAD for SQLServer" diese DLLs nicht auf, obwohl sie laut Dependency Walker eingebunden und geladen wurden.
Ich denke mal das TOAD irgendwelche Highlevel-Bibliotheken von C# benutzt. Aber müssten diese nicht letztendlich DLLs aus windows/system32 aufrufen, um mit dem SQLServer zu kommunizieren?
Hat jemand eine Idee, welche DLLs das sein könnten?Gibt es eine andere Art (unter C#), Proxy-DLLs zu erstellen?
Da die Clientsoftware nicht von uns kommt, können wir sie nicht verändern, deswegen muss eine der System-DLLs als Proxy dienen.
Wie könnte man das anstellen?
-
Kann man so etwas vielleicht mit einem ADO.NET Provider bewerkstelligen?
Man gibt sich als der "echte" SQLServer-Provider aus und klingt sich ins System, so das die Clients diesen Provider aufrufen?
Habe noch nie mit ADO.NET gearbeitet, nur zufällig eben mit Google darüber gestolpert
-
Hmm das scheint auch nicht zu gehen. Ich müsste einen Custom-Data-Provider erstellen, der den selben Namen trägt wie der originale Provider, also SqlClient. Aber das schlägt wohl schon fehl, da SqlClient in System.Data definiert ist, eine DLL, die ich nicht mal so einfach durch was eigenes austauschen kann.
Kennt eventuell jemand eine andere Möglichkeit, den "Default"-SQL-DataProvider zu ändern?
Ohne irgendwelche "Dirty hacks", ganz legal?
-
Hmm scheint leider niemand eine Idee zu haben... Ich habe mir nun auch mal das "Trace-Interface" von SQLServer angeschaut, aber leider ist das auch nicht das Wahre. Man kann zwar Traces manipulieren und zurückspielen (replay), aber das löst leider mein Problem auch nicht.
-
Ich werde es nun über einen Proxy-Server lösen, der die entsprechenden TDS-Pakete analysiert und dann entweder blockt oder sonst wie manipuliert.