SetNamedSecurityInfo 是 Windows 底层原子设置文件 DACL 的唯一可靠 API；需用绝对路径、有效 SID、管理员权限，配合 EXPLICIT_ACCESS 和 SetEntriesInAcl 构造 ACL，避免使用 SetFileSecurity 或硬编码用户名。
怎么用 SetNamedSecurityInfo 设置文件 ACL（Windows 底层）
直接调用 Windows API 是唯一真正细粒度控制文件 ACL 的方式，icacls 或属性 GUI 都是封装，没法满足底层定制需求。核心函数是 SetNamedSecurityInfo，它能原子性地写入 DACL（自主访问控制列表），不依赖 shell 或 .NET。
实操要点：
- 必须用
LPCTSTR（即LPCWSTR）传入完整绝对路径，相对路径、短文件名（8.3）、UNC 路径带尾部反斜杠都会失败，错误码通常是ERROR_INVALID_PARAMETER - 权限需通过
EXPLICIT_ACCESS结构逐条构造，不能靠“继承+修改”这种高层逻辑；每条必须指定grfAccessPermissions（如GENERIC_READ）、grfAccessMode（SET_ACCESS/DENY_ACCESS）、Trustee（含 SID） - 调用前需确保进程有
SE_SECURITY_NAME权限（通常需管理员 token），否则返回ERROR_PRIVILEGE_NOT_HELD；普通用户即使对文件有 Full Control 也无法改其 DACL - 不要手动拼接
ACCESS_ALLOWED_ACE结构——用SetEntriesInAcl将EXPLICIT_ACCESS数组转成有效PACL，它会处理 ACE 大小、顺序、继承标志等细节
怎么获取和验证目标用户的 SID（避免 ERROR_INVALID_SID）
ACL 条目里 Trustee 字段不是用户名字符串，而是二进制 SID。硬编码字符串（如 "Everyone"）或调用 LookupAccountName 失败，是 ACL 设置静默失败的最常见原因。
安全做法：
- 用
ConvertStringSidToSid解析已知 SID 字符串（如"S-1-5-32-545"对应 Users 组），比查账户名更稳 - 若需当前登录用户 SID，优先取
GetTokenInformation+TokenUser，而非LookupAccountName(GetUserName())—— 后者在域环境可能跨域解析失败 - 调用
IsValidSid检查生成的 SID 指针是否有效，无效 SID 会导致SetNamedSecurityInfo返回ERROR_INVALID_SID且不提示具体哪条出错 - 注意：
BUILTIN\Users和NT AUTHORITY\Authenticated Users是不同 SID，权限语义完全不同，别混用
为什么 SetFileSecurity 不推荐（兼容性与精度问题）
SetFileSecurity 看似更直接，但它要求传入完整 SECURITY_DESCRIPTOR 结构，而该结构中 DACL 指针必须指向 *已初始化* 的内存块。新手常犯错误是只分配 sizeof(ACL) 却没调用 InitializeAcl，结果触发 ERROR_INVALID_PARAMETER。
相比 SetNamedSecurityInfo，它还有两个硬伤：
- 不支持对符号链接目标设置 ACL（只作用于链接本身），而
SetNamedSecurityInfo默认操作目标文件 - Windows 10 1809+ 对某些系统文件（如
C:\Windows\System32下）会静默忽略 DACL 修改，除非显式加SE_GROUP_DEFAULT_ADMINISTRATOR标志，而SetNamedSecurityInfo可通过SE_OBJECT_TYPE参数明确指定对象类型 - 无法单独更新 DACL 而不影响 SACL 或 Owner，容易误清空审计策略
ACL 生效后为什么程序仍被拒绝访问？
设置了 DACL 不等于权限立即可用，Windows 访问检查是实时的，但受多个隐含条件制约：
- 进程 token 中的 group SIDs 必须与 DACL 中允许的 SID 匹配——如果用户属于多个组，而 DACL 只放行其中某个组，其他组权限不叠加；用
whoami /groups确认实际生效的组 - 父目录的继承权限可能覆盖文件级设置。检查是否禁用了继承（
SE_DACL_PROTECTED标志），否则子文件的 DACL 会被父目录策略重置 - UAC 虚拟化会干扰真实 ACL 效果：标准用户尝试写
C:\Program Files下文件时，系统自动重定向到%LOCALAPPDATA%\VirtualStore，你设的 ACL 其实作用在重定向后的路径上 - 杀毒软件或 EDR 可能 hook NtCreateFile 并额外拦截，此时
GetLastError()仍是ERROR_ACCESS_DENIED，但真实原因是驱动层过滤，不是 ACL 本身问题
细粒度 ACL 的麻烦点不在设置动作本身，而在验证路径、SID、token 权限、继承链、UAC 和第三方干预这五层嵌套上。少查一层，就卡半天。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
