acl拒绝规则在.net中不可靠，因deny易被allow覆盖且.net不校验ace顺序；应使用setaccessrule、显式设置继承标志、避免modify等组合权限，并优先移除allow而非添加deny。
ACL 拒绝规则在 .NET 中根本不可靠
windows ACL 的 Deny 条目在 .NET 的 FileSystemAccessRule 中能创建，但多数场景下它不会按你预期生效——尤其当用户属于多个组时，只要任意一条 Allow 规则覆盖了相同权限，Deny 就被绕过。这不是 bug，是 Windows 安全模型的设计：拒绝优先于允许，但仅对“同一访问控制条目（ACE）评估路径”生效；而 .NET 的 FileSecurity 和 DirectorySecurity 在设置时不做 ACE 排序校验，容易把 Deny 插到 Allow 后面，导致它被忽略。
实操建议：
- 永远用
FileSystemRights.FullControl或具体权限（如FileSystemRights.Read）配合AccessControlType.Deny，别用FileSystemRights.Modify这类组合值——它隐含子权限，可能和已有Allow冲突 - 添加拒绝规则前，先调用
GetAccessRules(true, true, typeof(NTAccount))检查当前 ACE 顺序，确保Deny出现在所有相关Allow之前 - 拒绝规则必须显式指定
InheritanceFlags和PropagationFlags，否则只作用于对象本身，不继承——比如想阻止子文件夹读取，得设InheritanceFlags.ContainerInherit | InheritanceFlags.ObjectInherit
用 FileSecurity.SetAccessRule() 添加拒绝规则的正确姿势
直接 new 一个 FileSystemAccessRule 并 Add 是错的——Add 不保证顺序，且会忽略已存在的冲突规则。必须用 SetAccessRule() 替换（或先 Remove 再 Add）。
常见错误现象：UnauthorizedAccessException 没出现，或用户仍能删除文件——大概率是拒绝规则没生效，或被更高层的组策略覆盖。
示例关键片段：
var sec = file.GetAccessControl(); var denyRule = new FileSystemAccessRule( "DOMAINUser", FileSystemRights.Read, InheritanceFlags.ContainerInherit | InheritanceFlags.ObjectInherit, PropagationFlags.None, AccessControlType.Deny); sec.SetAccessRule(denyRule); // 注意：不是 AddAccessRule file.SetAccessControl(sec);使用场景：
- 临时隔离某个用户对日志目录的读取（但保留管理员访问）
- 在部署脚本中封禁特定服务账户对配置文件的写入
为什么 GetAccessControl().AddAccessRule() 会静默失败
AddAccessRule() 只在规则完全不重复时才添加；如果已存在同主体、同权限、同继承标志的 Allow 规则，它不会报错，也不会覆盖，而是直接跳过——你看到代码执行成功，实际 ACL 毫无变化。
性能与兼容性影响：
- .NET 5+ 对
SetAccessControl的底层调用更严格，若目标路径有符号链接或重解析点，可能抛IOException；而旧版 .NET Framework 可能静默降级 - 在容器化环境（如 Windows Server Core 镜像）中，
SeTakeOwnershipPrivilege缺失会导致设置拒绝规则失败，错误信息是System.UnauthorizedAccessException: Attempted to perform an unauthorized operation. - 拒绝规则对内置账户（如
BUILTINAdministrators）基本无效——系统默认赋予其SE_TAKE_OWNERSHIP_NAME特权，可绕过 ACL
替代方案比硬塞 Deny 更可靠
真要限制访问，优先考虑移除不必要的 Allow，而不是加 Deny。ACL 是白名单思维，不是黑名单。
实操建议：
- 用
RemoveAccessRuleAll()清掉目标用户的全部现有规则，再用SetAccessRule()加入精确的Allow列表 - 对敏感目录，改用
Encrypting File System (EFS)加密，比 ACL 拒绝更防绕过 - 在应用层做二次校验：即使 ACL 允许，打开文件前仍检查当前
WindowsIdentity.GetCurrent().Name是否在许可名单里
最常被忽略的一点：拒绝规则对“创建文件”和“删除文件”是两个独立权限（FileSystemRights.CreateFiles vs FileSystemRights.delete），设错一个，用户就能绕开——比如只拒读不拒删，ta 仍可删完重建。