Sichere Debugging für die Produktion JVMs

Wir haben einige Anwendungen, die manchmal in einem schlechten Zustand, aber nur in der Produktion (natürlich!). Während der Einnahme ein heap-dump kann helfen, sammeln Sie Status-Informationen, ist es oft einfacher, einen remote-debugger. Die Einstellung ist leicht -- man muss nur hinzufügen, dass dies auf seinen Befehl Linie:

-Xdebug -Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=PORT

Scheint es keine verfügbaren Sicherheits-Mechanismus, also einschalten debugging in der Produktion würde der effektive Ausführung von beliebigem code ermöglichen (via hotswap).

Haben wir einen mix von 1.4.2 und 1.5 Sun-JVM unter Solaris 9 und Linux (Redhat Enterprise 4). Wie können wir ermöglichen das sichere debugging? Andere Wege, unser Ziel zu erreichen, Produktions-server inspection?

Update: Für JDK 1.5+ JVMs, kann man angeben, ein interface und port, an den der debugger sollte binden. So, KarlP Vorschlag von Bindung auf loopback und nur mit einem SSH-tunnel zu einem lokalen Entwickler-box funktionieren sollte gegeben SSH korrekt eingerichtet ist, auf den Servern.

Allerdings scheint es, dass JDK1.4x nicht erlauben, eine Schnittstelle spezifiziert, die für die debug-port. So können wir entweder blockieren Sie den Zugriff auf den debug-port irgendwo im Netz oder einige system-spezifische Blockierung im Betriebssystem selbst (IPChains als Jared vorgeschlagen, etc.)?

Update #2: Dies ist ein hack, lassen Sie uns begrenzen unser Risiko, auch auf 1.4.2 JVM:

Befehl Linie params:

-Xdebug
-Xrunjdwp:
    transport=dt_socket,
    server=y,
    suspend=n,
    address=9001,
    onthrow=com.whatever.TurnOnDebuggerException,
    launch=nothing

Java-Code zu aktivieren debugger:

try {
    throw new TurnOnDebuggerException();
} catch (TurnOnDebugger td) {
   //Nothing
}

TurnOnDebuggerException werden kann-ohne Ausnahme garantiert nicht geworfen werden, sonst nirgends.

Getestet habe ich diese auf einer Windows box um zu beweisen, dass (1) der debugger-port keine verbindungen empfangen werden zunächst, und (2) werfen die TurnOnDebugger Ausnahme, wie oben gezeigt, bewirkt, dass der debugger lebendig zu werden. Der Start-parameter erforderlich war (zumindest auf JDK1.4.2), aber einen Müll-Wert behandelt wurde, die sich anmutig durch die JVM.

Planen wir für Sie eine kleine servlet, das sich hinter entsprechende Sicherheit, kann es uns ermöglichen, schalten Sie den debugger. Natürlich kann man ihn nicht ausschalten danach, und der debugger noch hört promiscuously einmal seine auf. Aber, dies sind die Einschränkungen, die wir bereit sind zu akzeptieren, wie das Debuggen eines Produktionssystems wird immer nur ein Neustart danach.

Update #3: ich landete schriftlich drei Klassen: (1) TurnOnDebuggerException, ein plain 'ol Java-Ausnahme, (2) DebuggerPoller, einen hintergrund-thread, der überprüft das Vorhandensein einer bestimmten Datei auf dem Dateisystem, und (3) DebuggerMainWrapper, a-Klasse, startet das polling-thread und dann nachdenklich ruft die main-Methode der anderen Klasse.

Dies ist, wie Ihre verwendet:

1. Ersetzen "main" - Klasse mit DebuggerMainWrapper in Ihrem start-up-Skripte
2. Fügen Sie zwei system (-D) params, eine Angabe, die eigentliche Haupt-Klasse und das andere die Angabe einer Datei auf dem filesystem.
3. Konfigurieren Sie den debugger von der Kommandozeile mit der onthrow=com.was auch immer.TurnOnDebuggerException Teil Hinzugefügt
4. Fügen Sie ein Glas mit den drei Klassen, die oben erwähnten, um den classpath.

Nun, wenn Sie, starten Sie die JVM ist alles das gleiche, außer, dass ein hintergrund-poller-thread gestartet wird. Vorausgesetzt, dass die Datei (von uns genannt wird TurnOnDebugger) nicht ursprünglich vorhanden ist, die poller überprüft es alle N Sekunden. Wenn der poller zunächst bemerkt es, wirft es und sofort ins TurnOnDebuggerException. Dann wird der agent gestartet.

Können Sie nicht schalten Sie ihn wieder aus, und die Maschine ist nicht sehr sicher, wenn seine auf. Auf der anderen Seite, ich glaube nicht, dass der debugger ermöglicht mehrere gleichzeitige verbindungen, so dass die Wartung eine debugging-Verbindung ist die beste Verteidigung. Wir wählten die Datei notification-Methode, denn es erlaubt uns, um mit der Bahn aus der vorhandenen Unix-Authentifizierung/Autor durch die Angabe der trigger-Datei in ein Verzeichnis, auf das nur die richtigen verwendet haben Rechte. Sie könnte leicht zu bauen ein wenig Krieg-Datei, erreicht den gleichen Zweck über eine socket-Verbindung. Natürlich, da können wir nicht schalten Sie den debugger, wir werden es nur verwenden, um Daten zu sammeln, bevor das töten von Kranken-Anwendung. Wenn jemand möchte, dass dieser code, lassen Sie es mich bitte wissen. Jedoch, es dauert nur ein paar Minuten, werfen Sie es selbst zusammen.