哪些代码可能对环境（变量）敏感？答案

【问题标题】：Which code is potentially sensitive to environment (variables)?哪些代码可能对环境（变量）敏感？
【发布时间】：2016-03-29 14:04:14
【问题描述】：

我这里有一些（遗留）代码似乎在LD_LIBRARY_PATH 上调用setenv（编译时未知的值，实际上它将从命令行获取），现在我必须将它移植到视窗。我怀疑setenv只是出于历史原因，它已经没有实际效果了，我想确认一下。

所以我的方法是审查环境的所有用途，看看是否有任何人会受到LD_LIBRARY_PATH（或任何其他）的影响。所以我认为除非environ 变量或某些函数被调用，否则代码将对环境不敏感（直接、间接或在后续代码中）。

我确定的（作为候选人）的职能是：

getenv
exec*
popen
system
dlopen和朋友们
仅依赖于 TZ 变量的时间函数
依赖于语言环境且仅检索当前语言环境的函数

包含getenv 的原因很明显，因为后续代码可能取决于环境变量的值。包括exec*、popen和system是因为首先（子）程序的链接可能会受到环境的影响，而且（子）程序本身也可能依赖于环境，dlopen我认为会在LD_LIBRARY_PATH 中搜索库（同样，链接库本身可能在初始化期间或稍后访问环境）。剩下的就是因为我知道TZ 和语言环境正在标准库中的很多地方使用。

我是否错过了某些功能或其他代码可能取决于环境的情况？当然，我意识到这会受到加载的库的影响，但据我所知，只有加载的“标准”库加上libsqlite3（加上libpthread、libdl 和libm）。我猜SQLite3可能对一些环境变量很敏感，但是LD_LIBRARY_PATH是其中之一吗？

为了记录，这次程序似乎没有包含 exec* 或 dlopen，但我包含它们是因为在另一种情况下它们可能会包含在内。

【问题讨论】：

dlopen 让我想知道您的应用程序特定库是否是从 LD_LIBRARY_PATH 打开的。我将继续的方式是查看安装并检查 LD_LIBRARY_PATH 中使用的路径。检查应用程序指向的所有位置以及其中存在的库。
@Pradheep 恐怕这不可行。 LD_LIBRARY_PATH 设置的值在编译时未知。
为什么不将其打印到任何日志中并检查路径或在 gdb 中加载程序，这样更容易并在设置时检查值
数字格式取决于区域设置。时间、日期、货币格式取决于区域设置。一些整理（排序）算法依赖于语言环境。字符分类取决于区域设置（数字、大写、小写等）。大部分内容都包含在标准 C 库中（货币格式化没有用于该任务的标准 C 函数，但必要的信息存储在语言环境信息中）。
@JonathanLeffler 是的，这就是我将它们包括在内的原因。我希望这些功能也不依赖于LD_LIBRARY_PATH。

标签： c linux environment-variables

【解决方案1】：

您应该查看每个函数的文档。 dlopen 明确指出它使用 LD_LIBRARY_PATH 作为搜索列表来定位共享库。

当您在任何情况下都可以将路径指定为dlopen 的参数时，强制加载特定库似乎是一种相当笨拙的方式。

除此之外，它是 GNU 链接器 ld 用来定位 static 库的值。不太可能但可能的是，它被您的应用程序使用，因为它启动链接器或其他使用dlopen 的进程，例如，它可以通过exec、popen 或system 执行此操作。鉴于您的代码具有所有这些功能，很明显它正在启动一些外部进程。

【讨论】：

当您想强制加载特定库时，LD_LIBRARY_PATH 有很多有效用例，例如dlopen 调用不受您控制的任何时候，例如在第三方库中或在单独的进程中时。
检查文档是个好主意。我在手册页上运行了zgrep，还找到了uselib 函数。但是它会错过getenv 的案例以及启动其他程序的功能，这些程序可能会依赖LD_LIBRARY_PATH。
我认为您的问题已经得到解答；您需要分析代码以确定它为什么这样做。没有看到代码，我猜getenv() 用于获取当前的LD_LIBRARY_PATH，它预先或附加了一些特定于应用程序的路径，然后在调用dlopen() 之前使用setenv() 设置。我认为修改LD_LIBRARY_PATH 的方式会提供信息。您似乎正在寻找系统级别的东西，我认为这完全是特定于应用程序的。您选择不发布任何代码，所以我们只能猜测。