Gibt es eine Möglichkeit, die Umgebungsvariablen eines anderen Prozesses in Unix zu ändern?

Question

Unter Unix ist es eine Möglichkeit, dass ein Prozess eine andere Umgebungsvariablen des ändern können (vorausgesetzt, sie sind alle von demselben Benutzer ausgeführt wird)? Eine allgemeine Lösung wäre am besten, aber wenn nicht, was ist mit dem speziellen Fall, in dem man ein Kind des anderen ist?

Edit: Wie wäre es über gdb

Answer 1

Via GDB:

(gdb) attach process_id

(gdb) call putenv ("env_var_name=env_var_value")

(gdb) detach

Das ist ganz ein gemeiner Hack und soll nur im Zusammenhang mit einem Debug-Szenario durchgeführt werden, natürlich.

Answer 2

wahrscheinlich Sie es technisch tun kann (siehe andere Antworten), aber es könnte Ihnen nicht helfen.

Die meisten Programme erwarten, dass env vars nicht von außen nach dem Start geändert werden, damit die meisten werden wahrscheinlich lesen Sie einfach die Vars sie beim Start interessiert sind und initialisieren auf dieser Grundlage. So sie später ändern, werden keinen Unterschied machen, da das Programm nie wieder lesen sie.

Wenn Sie dies als ein konkretes Problem geschrieben, sollten Sie vielleicht einen anderen Ansatz. Wenn es nur aus Neugier: Nice Frage: -).

Answer 3

Im wesentlichen nicht. Wenn Sie ausreichende Berechtigungen (root, oder so ungefähr) hatte und stocherte / dev / kmem (Kernel-Speicher), und Sie Änderungen an der Umgebung des Prozesses, und wenn der Prozess tatsächlich die Umgebungsvariable danach wieder verwiesen (das heißt, der Prozess nicht bereits genommen eine Kopie des env var und wurde mit nicht nur diese Kopie) hatte, dann vielleicht, wenn man Glück hat und klug ist, und der Wind in der richtigen Richtung weht, und die Phase des Monds richtig war, vielleicht, Sie könnte etwas erreichen.

Answer 4

Zitiert von Jerry Peek:

  

Sie können nicht einen alten Hund neue Tricks beibringen.

Das einzige, was Sie tun können, ist die Umgebungsvariable des Kindes Prozess ändern vor Start es:. Es wird die Kopie der Elternumgebung, sorry

Siehe http://www.unix.com.ua/orelly /unix/upt/ch06_02.htm .

Nur ein Kommentar über die Antwort über die Verwendung von / proc. Unter Linux / proc unterstützt wird, aber, es funktioniert nicht, Sie kann nicht die /proc/${pid}/environ Datei ändern, auch wenn Sie als root angemeldet sind. Es ist absolut read-only

Answer 5

konnte ich denke, der eher gekünstelt Weg, dies zu tun, und es wird nicht für beliebige Prozesse arbeiten.

Nehmen wir an, dass Sie Ihre eigene gemeinsame Bibliothek schreiben, die ‚char * getenv‘ implementiert. Anschließend legen Sie ‚LD_PRELOAD‘ oder ‚LD_LIBRARY_PATH‘ env up. vars, so dass sowohl Ihre Prozesse laufen mit Ihrer gemeinsam genutzten Bibliothek vorinstalliert.

Auf diese Weise werden Sie haben im Wesentlichen eine Kontrolle über den Code der ‚getenv‘ -Funktion. Dann könnte man alle möglichen fiesen Tricks. Ihr ‚getenv‘ könnte externe Konfigurationsdatei oder SHM-Segment für alternative Werte von env vars konsultieren. Oder Sie könnten auf die gewünschten Werte regexp Suchen / Ersetzen tun. Oder ...

Ich kann nicht glauben, der eine einfache Möglichkeit, dass für beliebigen laufenden Prozess zu tun (auch wenn Sie als root angemeldet sind), kurz umschreiben dynamische Linker (ld-linux.so).

Answer 6

Oder erhalten Sie Ihren Prozess eine Konfigurationsdatei für den neuen Prozess zu aktualisieren und dann entweder:

• ein kill -HUP auf den neuen Prozess führen Sie die aktualisierte Konfigurationsdatei neu zu lesen, oder
• hat das Verfahren die Config-Datei ab und zu nach Updates suchen. Wenn Änderungen gefunden werden, dann die Konfigurationsdatei neu einzulesen.

Answer 7

Nicht so weit ich weiß. Wirklich Sie versuchen, von einem Prozess zu einem anderen zu kommunizieren, die für eine der IPC Methoden aufrufen (Shared Memory, Semaphore, Steckdosen, etc.). empfangenen Daten durch eine dieser Methoden haben könnten Sie dann Umgebungsvariablen oder andere Aktionen mehr direkt durchführen.

Answer 8

Wenn Ihr Unix das / proc-Dateisystem unterstützt, dann ist es trivial, die env zu lesen - Sie, die Umwelt, Kommandozeilen lesen können, und viele andere Attribute eines jeden Prozesses besitzen Sie auf diese Weise. Ändern es ... Nun, ich kann einen Weg finden, aber es ist eine schlechte Idee.

Der allgemeinere Fall ... Ich weiß nicht, aber ich bezweifle, gibt es eine portable Antwort.

(Edited: meine ursprüngliche Antwort nahm der OP wollte die env lesen, nicht ändern)

Answer 9

UNIX ist voll von Inter-Prozess-Kommunikation. Überprüfen Sie, ob Ihre Zielinstanz einige hat. Dbus ist ein Standard in "Desktop" IPC werden.

ich ändere Umgebungsvariablen innerhalb von ehrfürchtigem Window-Manager mit awesome-client mit einem Dbus ist "Sender" von lua-Code.

Answer 10

keine direkte Antwort, aber ... Raymond Chen hatte a [Windows-basierten] Gründe, um dieses nur den anderen Tag : -

  

... Zwar gibt es sicherlich nicht unterstützte Möglichkeiten, es oder Möglichkeiten zu tun, die mit Hilfe eines Debuggers arbeiten, gibt es nichts, was für programmatischen Zugriff auf einem anderen Prozess der Befehlszeile, zumindest nichts vorgesehen vom Kernel unterstützt wird. ...

     

Dass es nicht ist eine Folge des Grundsatzes der nicht aus den Informationen halten, die Sie nicht brauchen. Der Kernel hat keine Notwendigkeit, die Befehlszeile eines anderen Prozesses zu erhalten. Es nimmt die Befehlszeile an die CreateProcess Funktion übergeben und kopiert sie in den Adressraum des Prozesses ins Leben gerufen, in einem Ort, wo die GetCommandLine Funktion abgerufen werden kann. Sobald der Prozess seine eigene Befehlszeile zugreifen kann, sind die Kernel-Aufgaben durchgeführt.

     

Da die Befehlszeile in den Adressraum des Prozesses kopiert wird, kann der Prozess auch in den Speicher schreiben, der die Befehlszeile hält und es ändern. Wenn das passiert, dann wird die ursprüngliche Befehlszeile für immer verloren; die einzige bekannte Kopie überschrieben wurde.

Mit anderen Worten, solche kernel Einrichtungen wären

• schwer zu implementieren
• möglicherweise ein Sicherheitsproblem

Doch der wahrscheinlichste Grund ist einfach, dass es begrenzte Anwendungsfälle für eine solche Anlage.