☰

“CREATOR OWNER”NTFS 组在 Windows 中始终具有特殊权限

tag-icon • tag-icon windows file-permissions
“CREATOR OWNER”NTFS 组在 Windows 中始终具有特殊权限

我正在设置网络共享（见下文），在 NTFS 权限方面遇到了一些奇怪的行为。“创建者所有者”对象似乎只能在“安全”选项卡中列出“特殊”权限。无论我做什么，系统都会恢复到此设置。有没有办法让“创建者所有者”条目在安全选项卡中列出除特殊之外的任何内容？这将使检查权限错误变得容易得多，因为我不必深入到“高级”选项卡中查看我为该组设置的权限。这是在连接到 Windows Server 2008 共享的 Windows 7 客户端上。

附加问题：

我还想知道为什么“创建者所有者”组无法将权限应用于“此文件夹”。这似乎是该组的一个怪癖，它背后一定有一个故事，为什么会这样设置。

我进行了一些搜索，找到了“权限如何工作”technet 文章。我浏览了有关“OWNER”权限的信息，只找到了一些关于该权限如何运作的信息。

【背景故事】

因此，我有一个网络共享，用户可以在其中创建一个文件夹来存储他们在特定项目上的工作。根据项目经理给我的参数，每个用户文件夹中的文件都是私有的。除了该参数之外，这个文件夹的用户会在一年中不断变化，有些用户只会变化几天。因此，为了尽可能降低管理开销，我设置了以下权限：

  • 用户组 - 允许 - 列出文件夹内容
  • 用户组 - 允许 - 写入
  • 创建者所有者 - 允许 - 修改

我设置了权限，点击确定，一切正常。后来，当我回来将内容管理器组添加到“安全”选项卡时，我注意到一些奇怪的事情。“创建者所有者”条目已从“修改”切换为“特殊”。我进入高级权限，我注意到“创建者所有者”仅适用于“仅子文件夹和文件”。然后我尝试将“应用于”下拉菜单重置为“此文件夹、子文件夹和文件”，但只要我点击“应用”，它就会切换回来。

谢谢

答案1

CREATOR OWNER 访问控制条目应始终为仅继承，因为它们不适合应用于任何实际对象。使用带有现代 API 的较新版本的 Windows 时，所有 CREATOR OWNER 条目都会自动标记为仅继承。

在高级 GUI 中，仅继承标志翻译为“仅子文件夹和文件”。将其更改为“此文件夹、子文件夹和文件”将清除仅继承标志，而对于 CREATOR OWNER 则无法执行此操作。基本 GUI 可能不应将其显示为特殊，但我猜 MS 没有想到这种特殊情况。

答案2

CREATOR OWNER 主要用于动态许可，因为人们在他们拥有常规权限的文件夹中创建内容，而不是懒惰许可。如果你这样想，这个概念可能更有意义。

答案3

这只是 Linux 中可用的 POSIX ACL 和 Windows ACL 之间的映射限制。

说到文件夹，在 POSIX ACL 中，您可以为文件夹内创建的项目分配默认权限。您可以为指定的用户和组明确执行此操作，但有两个默认值适用于要创建的文件/文件夹的未来所有者（用户和组）。

default:user::rwx
default:group::r-x

它们分别映射到CREATOR OWNER和CREATOR GROUP。它们不适用于当前目录，因此当您查看 Windows UI 时，您会看到它们适用于Subfolders and files only。Windows 会将其视为特殊权限并如此显示。

对于每个目录，您还将拥有分配给所有者和组的权限

user::rwx
group::rwx

然而，当 Windows 查询时，这些会立即转换为实际所有者和组。即使您也授予 CREATOR OWNER 对此文件夹的权限，此更改也会丢失 - 因为 Windows 会将其视为对实际所有者权限的更改。

因此，您可能会在 UI 中看到：

Unix User - Root   - Full Control, This folder only
Unix Group - Root  - Full Control, This folder only
CREATOR OWNER      - Full Control, Subfolders and files only
CREATOR GROUP      - Read and execute, Subfolders and files only

不幸的是，我不知道如何将其合并成更易读的内容。

处理 NFSv4 ACL 时，它会变得稍微不那么棘手......

答案4

权限“创建者所有者”-“此文件夹的子文件夹和文件”被系统限制为“仅限子文件夹和文件”。

创建者用户无法创建其文件夹。

相关内容