Pregunta

En Unix, ¿hay alguna forma en que un proceso pueda cambiar las variables de entorno de otro (asumiendo que todas están siendo ejecutadas por el mismo usuario)? Una solución general sería la mejor, pero si no, ¿qué pasa con el caso específico donde uno es un hijo del otro?

Editar: ¿Qué tal a través de gdb?

¿Fue útil?

Solución

Vía gdb:

(gdb) attach process_id

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

(gdb) detach

Este es un hack bastante desagradable y solo debe hacerse en el contexto de un escenario de depuración, por supuesto.

Otros consejos

Probablemente puede hacerlo técnicamente (ver otras respuestas), pero puede que no le sirva.

La mayoría de los programas esperarán que las variables env no se puedan cambiar desde el exterior después del inicio, por lo que la mayoría probablemente solo leerán las vars en las que están interesados ??al inicio y se inicializarán basándose en eso. Por lo tanto, cambiarlos después no hará una diferencia, ya que el programa nunca los volverá a leer.

Si publicaste esto como un problema concreto, probablemente deberías adoptar un enfoque diferente. Si fue solo por curiosidad: Buena pregunta :-).

Substancialmente, no. Si tenía suficientes privilegios (raíz o aproximadamente) y buscaba alrededor de / dev / kmem (memoria del núcleo) e hizo cambios en el entorno del proceso, y si el proceso realmente volvió a hacer referencia a la variable de entorno después (es decir, el proceso no había tomado ya una copia de la env var y no estaba usando solo esa copia), entonces quizás, si tenía suerte y era inteligente, y el viento soplaba en la dirección correcta, y la fase de la luna era correcta, tal vez, usted podría lograr algo

Citando a Jerry Peek:

  

No puedes enseñarle nuevos trucos a un perro viejo.

Lo único que puedes hacer es cambiar la variable de entorno del proceso hijo antes de iniciarlo: obtiene la copia del entorno principal, lo siento.

Consulte http://www.unix.com.ua/orelly /unix/upt/ch06_02.htm para más detalles.

Solo un comentario sobre la respuesta sobre el uso de / proc. Bajo linux / proc es compatible pero, no funciona, usted no puede cambiar el archivo / proc / $ {pid} / environ , incluso si es root: es absolutamente solo lectura

Podría pensar en la forma más bien artificial de hacerlo, y no funcionará para procesos arbitrarios.

Supongamos que escribe su propia biblioteca compartida que implementa 'char * getenv'. A continuación, configura 'LD_PRELOAD' o 'LD_LIBRARY_PATH' env. vars para que ambos procesos se ejecuten con la biblioteca compartida precargada.

De esta manera, esencialmente tendrá un control sobre el código de la función 'getenv'. Entonces, podrías hacer todo tipo de trucos desagradables. Su 'getenv' podría consultar el archivo de configuración externo o el segmento SHM para obtener valores alternativos de las variables env. O puede hacer una búsqueda / reemplazo de expresiones regulares en los valores solicitados. O ...

No puedo pensar en una forma fácil de hacerlo para procesos en ejecución arbitrarios (incluso si eres root), excepto para reescribir el vinculador dinámico (ld-linux.so).

O haga que su proceso actualice un archivo de configuración para el nuevo proceso y luego:

  • realice un kill -HUP en el nuevo proceso para volver a leer el archivo de configuración actualizado, o
  • haga que el proceso verifique el archivo de configuración en busca de actualizaciones de vez en cuando. Si se encuentran cambios, vuelva a leer el archivo de configuración.

No que yo sepa. Realmente está intentando comunicarse de un proceso a otro, lo que requiere uno de los métodos de IPC (memoria compartida, semáforos, sockets, etc.). Una vez que haya recibido los datos por uno de estos métodos, podría establecer variables de entorno o realizar otras acciones de forma más directa.

Si su Unix es compatible con el sistema de archivos / proc, entonces es trivial LEER el entorno: puede leer el entorno, la línea de comandos y muchos otros atributos de cualquier proceso que posea de esa manera. Cambiándolo ... Bueno, puedo pensar en una forma, pero es una mala idea.

El caso más general ... No lo sé, pero dudo que haya una respuesta portátil.

(Editado: mi respuesta original asumió que el OP quería LEER el env, no cambiarlo)

UNIX está lleno de comunicación entre procesos. Compruebe si su instancia de destino tiene algunos. Dbus se está convirtiendo en un estándar en " escritorio " IPC.

Cambio las variables de entorno dentro de Awesome window manager usando awesome-client con un Dbus " sender " de código lua.

No es una respuesta directa pero ... Raymond Chen tenía una justificación [basada en Windows] alrededor de esto solo el otro día : -

  

... Aunque ciertamente hay formas no compatibles de hacerlo o formas que funcionan con la ayuda de un depurador, no hay nada que sea compatible con el acceso programático a la línea de comandos de otro proceso, al menos Nada proporcionado por el núcleo. ...

     

Que no hay & # 8217; t es una consecuencia del principio de no llevar un registro de la información que usted no necesita. El kernel no necesita obtener la línea de comando de otro proceso. Toma la línea de comando que se pasa a la función CreateProcess y la copia en el espacio de direcciones del proceso que se está iniciando, en una ubicación donde la función GetCommandLine puede recuperarla. Una vez que el proceso puede acceder a su propia línea de comando, las responsabilidades del kernel & # 8217; se realizan.

     

Dado que la línea de comandos se copia en el espacio de direcciones del proceso, el proceso podría incluso escribir en la memoria que contiene la línea de comandos y modificarla. Si eso sucede, entonces la línea de comando original se pierde para siempre; la única copia conocida fue sobrescrita.

En otras palabras, cualquier instalación del núcleo sería

  • difícil de implementar
  • potencialmente una preocupación de seguridad

Sin embargo, la razón más probable es simplemente que hay casos de uso limitado para tales instalaciones.

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top