Est-il possible de changer les variables d'environnement d'un autre processus sous Unix?

Question

Sous Unix, un processus peut-il modifier les variables d'environnement d'un autre (en supposant qu'ils soient tous exécutés par le même utilisateur)? Une solution générale serait préférable, mais dans le cas contraire, qu'en est-il du cas particulier où l'un est l'enfant de l'autre?

Edit: que diriez-vous de via gdb?

Answer 1

Via gdb:

(gdb) attach process_id

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

(gdb) detach

Ceci est un vilain bidouillage et ne devrait être fait que dans le contexte d'un scénario de débogage, bien sûr.

Answer 2

Vous pouvez probablement le faire techniquement (voir d'autres réponses), mais cela pourrait ne pas vous aider.

La plupart des programmes s’attendent à ce que les vars env ne puissent pas être modifiés de l’extérieur après le démarrage. Par conséquent, la plupart liront probablement les vars qui les intéressent au démarrage et s’initialisent en fonction de cela. Donc, les changer ensuite ne fera aucune différence, car le programme ne les relira jamais.

Si vous avez posté ceci comme un problème concret, vous devriez probablement adopter une approche différente. Si c'était juste par curiosité: bonne question: -).

Answer 3

Essentiellement, non. Si vous disposez de privilèges suffisants (racine ou à peu près) et que vous modifiez l’environnement du processus avec / dev / kmem (mémoire du noyau), et si le processus a re-référencé par la suite la variable d’environnement (c’est-à-dire n’avait pas déjà pris une copie de l’env et n’utilisait pas uniquement cette copie), alors peut-être, si vous étiez chanceux et intelligent, et que le vent soufflait dans la bonne direction et que la phase de la lune était correcte, peut-être, vous pourriez réaliser quelque chose.

Answer 4

Citant Jerry Peek:

  

Vous ne pouvez pas apprendre à un vieux chien de nouveaux tours.

La seule chose à faire est de modifier la variable d'environnement du processus enfant avant de la démarrer: la copie de l'environnement parent est récupérée.

Voir http://www.unix.com.ua/orelly /unix/upt/ch06_02.htm pour plus de détails.

Juste un commentaire sur la réponse concernant l'utilisation de / proc. Sous linux / proc est pris en charge, mais cela ne fonctionne pas, vous ne pouvez pas modifier le fichier / proc / $ {pid} / environ , même si vous êtes root: il est absolument en lecture seule.

Answer 5

Je pourrais penser à une manière assez artificielle de le faire, et cela ne fonctionnera pas pour des processus arbitraires.

Supposons que vous écriviez votre propre bibliothèque partagée qui implémente 'char * getenv'. Ensuite, vous configurez env. 'LD_PRELOAD' ou 'LD_LIBRARY_PATH'. vars afin que vos deux processus soient exécutés avec votre bibliothèque partagée préchargée.

De cette façon, vous aurez essentiellement un contrôle sur le code de la fonction 'getenv'. Ensuite, vous pourriez faire toutes sortes de mauvais tours. Votre "getenv" pourrait consulter un fichier de configuration externe ou un segment SHM pour connaître les valeurs alternatives de vars. Ou vous pouvez faire des recherches rationnelles / remplacer sur les valeurs demandées. Ou ...

Je ne vois pas de moyen facile de le faire pour les processus en cours d'exécution arbitraire (même si vous êtes root), à moins de réécrire l'éditeur de liens dynamique (ld-linux.so).

Answer 6

Ou demandez à votre processus de mettre à jour un fichier de configuration pour le nouveau processus, puis:

• effectuez un kill -HUP sur le nouveau processus pour relire le fichier de configuration mis à jour, ou
• demandez au processus de vérifier le fichier de configuration pour des mises à jour de temps en temps. Si des modifications sont trouvées, relisez le fichier de configuration.

Answer 7

Pas pour autant que je sache. Vraiment, vous essayez de communiquer d’un processus à l’autre, ce qui nécessite l’une des méthodes IPC (mémoire partagée, sémaphores, sockets, etc.). Après avoir reçu les données par l’une de ces méthodes, vous pouvez ensuite définir des variables d’environnement ou effectuer d’autres actions plus directement.

Answer 8

Si votre unix prend en charge le système de fichiers / proc, il est alors trivial de LIRE l'environnement: vous pouvez lire l'environnement, la ligne de commande et de nombreux autres attributs de tout processus que vous possédez de cette manière. Le changer ... Bien, je peux penser à un moyen, mais c'est une mauvaise idée.

Le cas plus général ... Je ne sais pas, mais je doute qu'il existe une réponse portable.

(édité: ma réponse initiale supposait que l'OP voulait lire l'environnement, pas le modifier) ??

Answer 9

UNIX est plein de communications inter-processus. Vérifiez si votre instance cible en a. Dbus est en train de devenir un standard dans " desktop " IPC.

Je modifie les variables d'environnement à l'intérieur du gestionnaire de fenêtres Awesome à l'aide de awesome-client avec un expéditeur Dbus " de code lua.

Answer 10

Ce n'est pas une réponse directe, mais ... Raymond Chen avait une logique [basée sur Windows] autour de cela uniquement l'autre jour : -

  

... Bien qu’il existe certainement des méthodes non prises en charge ou fonctionnant avec l’aide d’un débogueur, rien n’est pris en charge pour l’accès par programme à la ligne de commande d’un autre processus, du moins aucune donnée par le noyau. ...

     

Cela n’est pas une conséquence du principe de ne pas garder trace des informations dont vous n’avez pas besoin. Le noyau n'a pas besoin d'obtenir la ligne de commande d'un autre processus. La ligne de commande transmise à la fonction CreateProcess est copiée dans l'espace d'adressage du processus en cours de lancement, à un emplacement où la fonction GetCommandLine peut le récupérer. Une fois que le processus peut accéder à sa propre ligne de commande, les responsabilités du noyau sont définies.

     

La ligne de commande étant copiée dans l’espace adresse du processus, celui-ci peut même écrire dans la mémoire contenant la ligne de commande et la modifier. Si cela se produit, la ligne de commande d'origine est définitivement perdue. la seule copie connue a été écrasée.

En d'autres termes, de telles installations du noyau seraient

• difficile à mettre en œuvre
• potentiellement un problème de sécurité

Cependant, la raison la plus probable est tout simplement que les cas d'utilisation d'un tel système sont limités.