在Unix中,是否有方法更改另一个进程的环境变量?

通过GDB:

(gdb) attach process_id

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

(gdb) detach

当然,这是一个非常讨厌的黑客行为,应该只在调试场景的上下文中进行。

你也许可以从技术上做到这一点(看其他答案),但这可能对你没有帮助。

大多数程序都希望env vars在启动后不能从外部进行更改,因此大多数程序可能只是读取它们在启动时感兴趣的var,并根据该var进行初始化。因此,以后更改它们不会有什么不同,因为程序永远不会重新读取它们。

如果您将此作为一个具体问题发布,那么您可能应该采用不同的方法。如果只是出于好奇:好问题:—)。

实际上,不是的。如果您有足够的特权(根目录或其他目录),并且在/dev/kmem(内核内存)周围进行了访问,并且您对进程的环境进行了更改,并且如果进程随后实际重新引用了环境变量(也就是说,进程还没有复制env var,并且没有使用该副本),那么,如果你运气好,聪明,风吹向正确的方向,月亮的相位是正确的,也许你会有所成就。

引用Jerry Peek的话:

你不能教老狗新把戏。

您唯一能做的就是更改子进程的环境变量 之前 启动:它得到父环境的副本,对不起。

见 http://www.unix.com.ua/orelly/unix/upt/ch06_02.htm 详情。

只是对有关使用/proc的答案的注释。在Linux/proc下是受支持的,但它不起作用,您 不能 改变 /proc/${pid}/environ 文件,即使您是根用户:它是 绝对地 只读的。

我可以想出一个相当人为的方法来做到这一点,它不适用于任意的过程。

假设您编写自己的共享库来实现“char*getenv”。然后,设置“ld_preload”或“ld_library_path”env。变量,以便在预加载共享库的情况下运行两个进程。

这样,您就基本上可以控制“getenv”函数的代码。然后,你可以做各种恶作剧。“getenv”可以查询外部配置文件或shm段以获取env vars的可选值。或者可以对请求的值执行regexp搜索/替换。或者…

对于任意运行的进程(即使您是根进程),我想不出一个简单的方法来实现这一点,除了重写动态链接器(ld linux.so)。

或者让您的进程更新新进程的配置文件,然后:

• 对新进程执行kill-hup以重新读取更新的配置文件,或者
• 让进程不时检查配置文件中的更新。如果发现更改,则重新读取配置文件。

Hth.

干杯,

抢劫

据我所知。实际上,您试图在一个进程与另一个进程之间进行通信,该进程调用一个IPC方法(共享内存、信号量、套接字等)。通过这些方法之一接收到数据后,您可以设置环境变量或更直接地执行其他操作。

如果您的UNIX支持/proc文件系统,那么读取env就很简单了——您可以通过这种方式读取任何进程的环境、命令行和许多其他属性。改变它…好吧,我想办法,但这是个坏主意。

一般情况下…我不知道,但我怀疑是否有便携式答案。

(编辑:我的原始答案假设OP想要阅读env,而不是更改它)

Unix充满了进程间通信。检查目标实例是否有。DBUS正在成为“桌面”工控机的标准。

我在Awesome窗口管理器内部使用 令人敬畏的客户 with是lua代码的dbus“sender”。

不是直接回答,而是… Raymond Chen had a [Windows-based] rationale around this only the other day -

…尽管确实存在不受支持的方法或在调试器的帮助下工作的方法,但对于对另一个进程的命令行的编程访问,没有任何支持,至少内核没有提供任何支持。…

没有“T”是不跟踪您不需要的信息的原则的结果。内核不需要获得另一个进程的命令行。它将命令行传递给 CreateProcess 函数并将其复制到正在启动的进程的地址空间中, GetCommandLine 函数可以检索它。一旦进程可以访问自己的命令行,内核的职责就完成了。

由于命令行被复制到进程的地址空间中,进程甚至可能会写入保存命令行的内存并对其进行修改。如果发生这种情况,那么原始命令行将永远丢失;唯一已知的副本将被覆盖。

换句话说,任何这样的内核设施

• 难以实施
• 潜在的安全问题

然而,最可能的原因仅仅是这种设施的使用案例有限。