本文旨在解决Java应用中JNA库在用户临时目录生成随机命名DLL文件，导致Windows AppLocker阻碍应用运行的问题。文章首先阐明AppLocker路径通配符的限制，指出其无法在路径中间使用通配符。随后，详细介绍通过配置JNA的库加载机制，将原生库预先提取到固定、已知位置的解决方案，并提供两种主要方法：利用`jna.boot.library.path`系统属性或放置到系统路径，从而实现AppLocker的精确控制，避免使用过于宽泛的通配符。
JNA临时文件与AppLocker的冲突
Java Native Access (JNA) 库允许Java程序轻松调用原生共享库（如Windows上的DLL文件）。然而，当JNA首次加载时，如果找不到预先配置的原生库，它通常会从JNA的JAR包中提取一个平台特定的原生库到用户的临时目录。这个临时目录的路径通常是%OSDRIVE%\Users\
这种随机命名机制给Windows AppLocker的配置带来了挑战。AppLocker是一种应用程序控制策略，用于限制用户可以运行的文件。为了允许Java应用正常运行，需要为JNA生成的DLL文件添加例外规则。然而，由于路径和文件名中的随机部分，为每个用户或每次运行手动添加规则是不切实际的。
AppLocker路径通配符的限制
面对上述问题，一种直观的想法是使用AppLocker的路径通配符来匹配随机部分，例如：
%OSDRIVE%\Users\ABC-
然而，根据AppLocker的官方文档，路径通配符（*）仅支持在路径的开头或结尾使用，而不能在路径的中间部分。这意味着上述包含中间通配符的规则将无法生效。如果强制使用一个过于宽泛的通配符（例如%OSDRIVE%\Users\*\AppData\Local\Temp\*），则可能会允许所有用户在临时目录中执行任意文件，这与AppLocker的安全目标相悖。
因此，直接通过AppLocker规则的路径通配符来解决JNA临时文件的问题是不可行的。更有效的策略是改变JNA库的加载行为，使其原生库始终位于一个固定且可预测的位置。
解决方案：JNA原生库的预提取与重定位
JNA提供了灵活的机制来控制其原生库的加载过程，这正是解决AppLocker问题的关键。通过将JNA的原生库预先提取到一个已知位置，并告知JNA从该位置加载，可以完全避免随机命名的临时文件问题。
JNA的加载顺序概览：
- 首先尝试从jna.boot.library.path系统属性指定的目录加载。
- 如果失败且jna.nosys=false（默认值），则尝试从系统库路径（如Windows的PATH环境变量或System32目录）加载。
- 最后，如果以上都失败，则尝试从JNA的JAR文件内部提取原生库到临时目录并加载。
基于此，我们有两种主要方法来控制JNA的原生库位置：
方法一：通过jna.boot.library.path指定自定义路径 (推荐)
这是最推荐的方法，因为它提供了最大的灵活性和控制力。您需要手动将JNA的原生库（例如Windows上的jna.dll或jna-platform.dll，Linux上的libjnidispatch.so）预先复制到一个您选择的固定目录，然后通过jna.boot.library.path系统属性告知JNA从该目录加载。
步骤：
获取JNA原生库： 从JNA的JAR文件中提取或从JNA的发布包中找到对应平台和架构的原生库文件（例如，jna.jar中通常包含com/sun/jna/win32-x86-64/jna.dll等）。
选择固定目录： 选择一个所有目标用户都有读取权限的固定目录，例如：C:\Program Files\YourApp\JNALibs\。
放置原生库： 将提取出的jna.dll（或其他平台对应的库）放置到上述固定目录中。
-
配置JNA加载路径：
-
通过Java命令行参数： 在启动Java应用程序时，添加-Djna.boot.library.path参数。
java -Djna.boot.library.path="C:\Program Files\YourApp\JNALibs" -jar YourApp.jar
-
在程序启动时设置系统属性： 在JNA类被首次访问之前，通过Java代码设置系统属性。
import com.sun.jna.Native; public class YourApplication { public static void main(String[] args) { // 在任何JNA相关代码之前设置此属性 System.setProperty("jna.boot.library.path", "C:\\Program Files\\YourApp\\JNALibs"); // 确保JNA不会尝试从JAR中解压 // System.setProperty("jna.nounpack", "true"); // 可选，如果确保库已存在于指定路径 // 之后可以正常使用JNA // Native.load(...); } } -
通过_JAVA_OPTIONS环境变量： 如果您运行的是一个可执行文件而不是直接的Java命令行，并且需要全局设置，可以考虑使用_JAVA_OPTIONS环境变量。
set _JAVA_OPTIONS=-Djna.boot.library.path="C:\Program Files\YourApp\JNALibs"
注意： 使用_JAVA_OPTIONS会影响所有Java应用程序，需谨慎。
-
方法二：放置到系统目录并禁用解压
这种方法是将JNA的原生库放置到操作系统默认的库搜索路径中（例如Windows的System32目录或PATH环境变量包含的目录），并确保JNA不会尝试从JAR包中解压。
步骤：
- 获取JNA原生库： 同方法一。
- 放置到系统目录： 将jna.dll放置到C:\Windows\System32\或其他已在系统PATH环境变量中的目录。 注意： 放置到System32通常需要管理员权限，且可能对系统造成更广泛的影响。
-
配置JNA禁用解压：
- 确保jna.nosys=false： 这是JNA的默认行为，表示JNA会尝试从系统路径加载。
-
设置jna.nounpack=true： 这个系统属性会阻止JNA从JAR文件中提取原生库到临时目录。
java -Djna.nounpack=true -jar YourApp.jar
或在代码中设置：
System.setProperty("jna.nounpack", "true");
对比两种方法：
-
方法一 (jna.boot.library.path)：
- 优点： 隔离性好，不污染系统目录；对路径有完全控制；AppLocker规则精确。
- 缺点： 需要手动管理原生库的部署。
-
方法二 (系统目录 + jna.nounpack)：
- 优点： 如果库已存在于系统路径，配置简单。
- 缺点： 可能需要管理员权限部署；对系统目录有依赖；AppLocker规则可能不够精确，如果系统路径中有其他非预期的DLL。
对于大多数企业级部署和安全性要求较高的场景，方法一是更优的选择。
关于java.io.tmpdir的说明
JNA在解压原生库时，会使用java.io.tmpdir系统属性指定的目录作为其临时文件的根目录。您可以通过以下方式修改java.io.tmpdir：
- 命令行： java -Djava.io.tmpdir=C:\YourApp\TempDir -jar YourApp.jar
- 环境变量： set _JAVA_OPTIONS=-Djava.io.tmpdir=C:\YourApp\TempDir
虽然修改java.io.tmpdir可以控制JNA临时文件生成的根目录，但JNA仍然会在该根目录下创建带有随机名称的子目录（例如jna--881477353）。因此，仅仅修改java.io.tmpdir并不能解决AppLocker路径通配符无法匹配随机子目录的问题。它主要用于管理Java应用程序的通用临时文件存储位置，而不是为JNA提供一个固定且完全可预测的库路径。
AppLocker规则配置
一旦您采用了上述任一方法将JNA的原生库放置到了一个固定、已知的路径（例如C:\Program Files\YourApp\JNALibs\jna.dll），AppLocker的配置就变得非常简单和精确。
您只需在AppLocker的DLL规则中添加一个允许规则，指定该DLL的完整固定路径即可：
- 打开本地组策略编辑器 (gpedit.msc) 或通过域组策略管理。
- 导航到 计算机配置 -> Windows 设置 -> 安全设置 -> 应用程序控制策略 -> AppLocker -> DLL 规则。
- 右键点击 DLL 规则，选择 创建新规则。
- 在向导中，选择 允许 动作，并指定受影响的用户或组。
- 选择 路径 作为条件类型。
- 输入JNA原生库的完整固定路径，例如：C:\Program Files\YourApp\JNALibs\jna.dll。
- 完成规则创建。
通过这种方式，AppLocker能够精确地识别并允许您的Java应用程序加载JNA原生库，而无需使用任何宽泛的通配符，从而确保了安全性和应用程序的正常运行。
总结
解决JNA临时DLL文件与Windows AppLocker冲突的关键在于避免JNA在随机路径生成文件。通过利用JNA提供的jna.boot.library.path系统属性，将JNA原生库预先部署到一个固定、可预测的目录，并相应地配置AppLocker规则，可以实现安全且高效的应用程序控制。这种方法不仅解决了AppLocker的路径通配符限制，也提升了应用程序的部署和管理便利性。在实施时，推荐使用jna.boot.library.path方案，因为它提供了最佳的隔离性和可控性。
