JavaPropertyPermission类使用详解

Java的PropertyPermission类专用于控制System.getProperty()的读取权限，仅在启用SecurityManager时生效，未授权将抛出SecurityException；其策略配置严格限定为"read"或"read,write"动作，支持精确键名、前缀通配（如"java.*"）和全局通配（"*"），但需注意语法细节与安全风险；尽管SecurityManager已在JDK 21被标记为待移除，该权限机制仍在沙箱、嵌入式及部分框架中实际发挥作用；然而现代开发更推荐通过封装配置访问、白名单过滤或依赖注入等主动设计替代繁琐且易出错的policy文件配置，既提升可维护性，又规避底层权限模型的兼容性陷阱。

PropertyPermission 是用来拦住 System.getProperty 的

它不控制 setProperty，只管 get。Java 安全管理器（SecurityManager）启用时，每次调用 System.getProperty("os.name") 这类操作，JVM 就会检查是否有对应的 PropertyPermission 授权。没授权就抛 SecurityException，错误信息通常是：java.lang.SecurityException: Access denied ("java.util.PropertyPermission" "os.name" "read")。

常见踩坑点：

• 以为加了 System.setProperty("x", "y") 就需要 read 权限 —— 不需要，write 权限是另一回事，而且默认策略里几乎不配 write
• 在容器或框架里（比如 Tomcat、Spring Boot）启用了 SecurityManager 却没调好 policy 文件，结果连 file.encoding 都读不到，应用启动失败
• 用通配符 "*" 申请权限时写成 "*"（带引号），实际 policy 文件里必须不带引号：permission java.util.PropertyPermission "*", "read";

policy 文件里怎么写 PropertyPermission 条目

格式固定：permission java.util.PropertyPermission "key", "actions";，其中 key 支持两种通配：

• "java.version" → 精确匹配单个属性
• "java.*" → 匹配以 java. 开头的所有 key（如 java.home、java.class.path）
• "*" → 匹配所有系统属性（慎用，尤其生产环境）

actions 只能是 "read" 或 "read,write"；注意："write" 单独写无效，必须和 "read" 一起（JVM 内部逻辑要求 read 是 write 的前提）。

示例（放在 java.policy 中）：

grant {
  permission java.util.PropertyPermission "user.dir", "read";
  permission java.util.PropertyPermission "java.*", "read";
};

SecurityManager 已被弃用，但 PropertyPermission 还在起作用

JDK 17 起 SecurityManager 默认禁用，且 JDK 21 标记为 @Deprecated(forRemoval = true)。但 PropertyPermission 类本身没删，也不打算删——它是 Java 权限模型的基础构件，只要安全管理机制还存在（比如某些嵌入式或沙箱环境），它就还有意义。

关键现实：

• 你写的代码如果显式调用 SecurityManager.checkPermission(new PropertyPermission(...))，运行时不会报错，但什么也不会发生（因为默认 manager 是 null）
• 第三方库（如老版本 Apache Commons Configuration）可能仍硬编码检查逻辑，遇到空 manager 就 NPE，得自己兜底
• Android、某些 IoT JVM 实现、或自定义 ClassLoader 沙箱，仍可能启用它，此时 PropertyPermission 行为完全生效

替代方案比死磕 PropertyPermission 更实际

真要限制属性访问，现代做法基本绕开 SecurityManager：

• 用 System.getProperties().stringPropertyNames() 做白名单过滤，而不是靠权限拦截
• 把敏感配置抽到 ConfigService 类中统一管理，对外只暴露方法接口，不暴露原始 System.getProperty
• 启动时用 -D 参数传参，再通过 Spring @Value 或 Micrometer 的 ConfigurableEnvironment 间接读取，天然隔离底层权限机制

硬配 policy 文件调试成本高，容易漏配、误配，而且不同 JDK 版本对通配符解析有细微差异（比如 "user.*" 在某些旧版里不包含 user.dir）。与其花半天调权限，不如改两行代码把属性读取封装掉。

真正难的不是写对那条 policy，而是搞清谁在什么时候、以什么方式触发了哪次 getProperty 调用 —— 日志里只报异常，不报栈帧来源。

以上就是《JavaPropertyPermission类使用详解》的详细内容，更多关于的资料请关注golang学习网公众号！