是否有 API 可以仅在特定文件夹上设置 NTFS ACL，而无需向下传递权限？
在我的环境中，我有几个项目涉及在多个文件服务器上运行 NTFS ACL 审核报告和各种 ACL 清理活动。 我无法在服务器上本地执行这些活动有两个主要原因：
1）我无法本地访问服务器，因为它们实际上由另一家公司拥有和管理。
2) 它们是 SNAP NAS 服务器，运行修改后的 Linux 操作系统（称为 GuardianOS） ）所以即使我可以获得本地访问权限，我也不确定是否有工具可以执行我需要的操作。
解决这个问题后，我最终推出了自己的 ACL 审计报告工具，该工具将从指定的顶级路径开始递归文件系统，并生成有关 ACL 上遇到的所有组/用户的 HTML 报告，如下所示以及显示从树下降时权限的变化。 在开发这个工具时，我发现网络开销是执行这些操作的最糟糕的部分，通过多线程处理过程，我可以获得显着更高的性能。
然而，我仍然在寻找一个好的工具来执行 ACL 修改和清理。 您的标准开箱即用工具（cacls、xcacls、Explorer）似乎是单线程的，并且在穿越网络时会遭受显着的性能损失。 我已经考虑过滚动我自己的多线程 ACL 设置程序，但我熟悉的唯一 API 是 .NET FileSystemAccessRule 内容，问题是如果我在文件夹中设置权限，它会自动想要“流动”权限下降。 这会导致一个问题，因为我想使用多线程自己进行“流动”。
我知道 NTFS“允许”继承的权限不一致，因为我看到文件夹/文件在具有不同继承权限的两个父文件夹之间的同一卷上移动，并且它将旧权限保留为“继承”。
问题
1) 有没有办法设置适用于当前文件夹和所有子文件夹的 ACL（您的标准“适用于文件、文件夹和子文件夹”ACL），但不让它自动向下流动到子对象？ 基本上，我希望能够告诉 Windows“是的，这个 ACL 应该应用于子对象，但现在，只需直接在该对象上设置它”。
为了清楚起见，我知道适用于“仅此文件夹”的 ACL 选项，但随后我失去了继承，这是一项要求，因此该选项对我的用例无效。
2) 任何人知道以多线程方式执行 ACL 修改的任何好的算法或方法吗？ 我的直觉是，理论上，文件系统的任何递归遍历都应该有效，特别是如果您只是在顶级文件夹上定义新的 ACL 并且只想“清理”所有子文件夹。 您可以在顶层标记新的 ACL，然后向下递归删除任何显式 ACE，然后向下“流动”继承的权限。
（仅供参考，这个问题部分重复 来自 ServerFault，因为它实际上既是系统管理员又是编程问题。在另一个问题上，我问是否有人知道可以通过网络进行快速 ACL 设置的工具。）
In my environment, I have several projects that involve running NTFS ACL audit reports and various ACL cleanup activities on a number of file servers. There are two main reasons why I cannot perform these activities locally on the servers:
1) I do not have local access to the servers as they are actually owned and administered by another company.
2) They are SNAP NAS servers which run a modified Linux OS (called GuardianOS) so even if I could get local access, I'm not sure of the availability of tools to perform the operations I need.
With that out of the way, I ended up rolling my own ACL audit reporting tool that would recurse down the filesystem starting at a specified top-level path and would spit out an HTML report on all the groups/users it encountered on the ACLs as well as showing the changes in permissions as it descended the tree. While developing this tool, I found out that the network overhead was the worst part of doing these operations and by multi-threading the process, I could achieve substantially greater performance.
However, I'm still stuck for finding a good tool to perform the ACL modifications and cleanup. Your standard out of the box tools (cacls, xcacls, Explorer) seem to be single-threaded and suffer significant performance penalty when going across the network. I've looked at rolling my own ACL setting program that is multithreaded but the only API I'm familiar with is the .NET FileSystemAccessRule stuff and the problem is that if I set the permissions at a folder, it automatically wants to "flow" the permissions down. This causes a problem because I want to do the "flowing" myself using multi-threading.
I know NTFS "allows" inherited permissions to be inconsistent because I've seen it where a folder/file gets moved on the same volume between two parent folders with different inherited permissions and it keeps the old permissions as "inherited".
The Questions
1) Is there a way to set an ACL that applies to the current folder and all children (your standard "Applies to files, folders, and subfolders" ACL) but not have it automatically flow down to the child objects? Basically, I want to be able to tell Windows that "Yes, this ACL should be applied to the child objects but for now, just set it directly on this object".
Just to be crystal clear, I know about the ACL options for applying to "this folder only" but then I lose inheritance which is a requirement so that option is not valid for my use case.
2) Anyone know of any good algorithms or methodologies for performing ACL modifications in a multithreaded manner? My gut feeling is that any recursive traversal of the filesystem should work in theory especially if you're just defining a new ACL on a top-level folder and just want to "clean up" all the subfolders. You'd stamp the new ACL on the top-level and then recurse down removing any explicit ACEs and then "flowing" the inherited permissions down.
(FYI, this question is partially duplicated from ServerFault since it's really both a sysadmin and a programming problem. On the other question, I was asking if anyone knows of any tools that can do fast ACL setting over the network.)
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
在 MS 知识库文章中找到了答案：
因此，我必须使用低级 SetFileSecurity Win32 API 函数（该函数在其 MSDN 条目）来设置 ACL，这应该可以防止它自动向下流动。
当然，我宁愿用勺子把我的眼球挖出来，也不愿尝试 P/Invoke 一些遗留的 Win32 API，这样我最终可能只使用一个名为 FILEACL 类似于 CACLS，但可以选择使用 SetFileSecurity API，因此更改不会自动向下传播。
Found the answer in a MS KB article:
So I've got to use the low-level SetFileSecurity Win32 API function (which is marked obsolete in its MSDN entry) to set the ACL and that should keep it from automatically flowing down.
Of course, I'd rather tear my eyeballs out with a spoon rather than deal trying to P/Invoke some legacy Win32 API with all its warts so I may end up just using an old NT4 tool called FILEACL that is like CACLS but has an option to use the SetFileSecurity API so changes don't automatically propagate down.