PropertyPermission仅控制System.getProperty的读取权限，不涉及setProperty；启用SecurityManager时会检查该权限，未授权则抛SecurityException；其策略格式为permission java.util.PropertyPermission "key", "actions";，actions仅支持"read"或"read,write"；虽SecurityManager已弃用，但PropertyPermission仍在沙箱等场景有效；现代方案倾向封装属性访问而非依赖权限机制。
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免费学习笔记（深入）”；
示例（放在 java.policy 中）：
分析 Java Spring Boot 后端 Controller 代码，自动生成 Markdown 格式的接口文档。当用户说“生成 Java 接口文档”、“生成 API 文档”、“从 Spring 代码生成文档”时触发。
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 调用 —— 日志里只报异常，不报栈帧来源。
