调用Windows API设置文件权限服务端报错5/1008如何解决

• 错误码5（ERROR_ACCESS_DENIED）：Tomcat默认以Local Service、Network Service等低权限服务账号运行，这类账号默认没有修改目标文件安全描述符的权限。而你本地运行程序时用的是个人登录账号（通常有对应文件的所有权或修改权限），所以不会触发该错误。
• 错误码1008（ERROR_NO_TOKEN）：你的C++代码硬编码了受托人名称为_T("CURRENT_USER")，服务运行环境中没有交互式用户的会话令牌，系统无法识别CURRENT_USER指代的用户对象，因此调用ACL相关接口时抛出该错误。
• 额外代码风险：你在grantAccess方法中存在内存泄漏和编码转换错误：先申请了31位的TCHAR数组后直接把指针指向file.c_str()，不仅申请的内存没有释放，若程序为Unicode编译，多字节的std::string强转成宽字符指针会导致文件名乱码，也可能触发权限调用失败。

1. 代码层修复

• 去掉CURRENT_USER硬编码，将受托人名称改为参数从Java层传入，或者固定为你实际要授权的账号名（比如Tomcat运行账号、Web访问用户对应的系统账号）。
• 修复文件名编码转换逻辑：Unicode编译场景下使用MultiByteToWideChar接口把std::string类型的文件名转换为宽字符，不要直接强转指针，同时释放不必要的内存申请避免泄漏。
• 补充错误日志，打印每次调用的文件名、授权账号、错误码，方便后续排查问题。

2. 服务权限配置

• 调整Tomcat服务的运行账号：优先选择仅拥有目标文件存储目录权限的专用账号运行Tomcat，不要直接用管理员账号运行（会带来安全风险）。
• 调整目标存储目录权限：不要把业务文件存放在普通用户桌面、系统目录等受限路径，单独规划文件存储目录，提前给Tomcat运行账号授予该目录的「修改安全描述符」和读写权限。

• 优先使用Java原生API实现权限控制：JDK7及以上版本提供了java.nio.file.attribute.AclFileAttributeView类，可以直接操作Windows系统的文件ACL，不需要通过JNI跨语言调用，可维护性、稳定性更高，也避免了JNI可能引发的内存泄漏、JVM崩溃问题。
• 权限逻辑上移到业务层：不要动态修改文件系统层面的ACL，提前按业务角色规划独立的文件存储目录，目录权限提前配置完成，访问控制逻辑在业务层实现，性能更高也不会出现系统权限不足的问题。
• 若必须依赖系统级ACL控制，可以单独部署一个高权限运行的Windows权限管理服务，暴露内部RPC接口给Java后端调用，Java服务不需要额外提权，可降低整体安全风险。

内容的提问来源于stack exchange，提问作者Siva