chown（1）POSIX规范的说明

该chown实用程序的POSIX规范在其理论部分中提到了chown user:group语法（以前称为chown user.group）（强调我的语法）：

POSIX.1-2008的此卷中包含了同时指定所有者和组的4.3 BSD方法，因为：

• 在某些情况下，使用chgrp和chown（仅更改用户ID）实用程序无法达到所需的最终条件。（如果当前所有者不是所需组的成员，并且所需所有者不是当前组的成员，则除非所有者和组同时更改，否则chown（）函数可能会失败。）

我认为user:group语法很方便。现在，上述暗示有事情可以做chown user:group，你不能用chgrp group; chown user

现在，这段文字对我来说毫无意义。在4.3BSD中，只有root才能更改所有者的文件，因此无论如何他都没有限制。

SysV和其他一些系统允许（或用来允许）文件所有者将文件的用户和组更改为任何内容，但是即使在那些系统中，上面的文字对我来说也没有意义。好的，如果有人这样做了chown someone-else the-file，则不能再做chgrp something-else the-file，因为一个人不再是文件的所有者，但是并没有阻止他（她）做第chgrp一个文件（保持文件的所有者）和chown之后的事情，而那不是上面的文字准确地说。

我不了解和所希望的所有者不是当前组的成员与该问题有什么关系。

那么，除非所有者和组都同时更改，否则chown（）函数可能会在哪些情况下失败？在什么系统上？

NT内核的Microsoft Interix Unix子系统 （现已淘汰）在用户和组权限上的处理与其他一些稍有不同：

用户和组信息存储在Security Access数据库中。用户和组都存储在同一个数据库中，但是组和用户名必须唯一。任何群组都不能使用用户名，反之亦然。（此数据库代替UNIX中的/etc/passwd和/etc/groups文件。）使用适当的Windows方法（用户管理器，Active Directory用户和计算机或本地用户和组）或Win32 net user命令创建用户和组。（目录中包含用于创建和删除用户的示例Shell脚本/usr/examples/admin。）用户可以属于多个组。

以下是一些更具体的手册摘录：

在Windows中，用户或组都可以拥有一个对象。这与UNIX不同，后者只有一个用户拥有一个对象。

Windows通过使用安全标识符（SID）在内部标识所有用户和组。散列算法生成唯一的SID值；没有两个用户或组具有相同的SID。

有权访问对象的用户和组由其SID标识。Windows可以保护的所有对象都有一个自由访问控制列表（DACL），该列表由称为访问控制条目（ACE）的单独条目组成。ACE包含两条重要信息：用户或组SID，以及对单个用户或组对对象的访问权限的描述。

玻璃钢

...更改文件的组ID ...调用chgrp（1）的用户必须属于指定的组，并且是文件的所有者，或具有适当的特权。

周恩来

...所有者和组操作数都是可选的；但是，必须指定一个。如果指定了组操作数，则必须在其后加上一个冒号（:)。

可以通过数字用户ID或用户名指定所有者。如果用户名也是数字用户ID，则将操作数用作用户名。该组可以是数字组ID或组名。如果组名也是数字组ID，则将操作数用作组名。

出于安全原因，只有拥有适当特权的进程才能更改文件的所有权。

如我所读，这意味着如果您的用户帐户属于Windows组，并且该用户组具有足够的特权来修改该组拥有的文件的权限，则可以有效地chgrp将该文件置于用户帐户控制之外。与使用chown和显式user:group参数相比，这意味着控制较少。在这种情况下user: ， :group如果没有声明的可能性，您将永远无法获得与其他结果相同的结果。

这里是详细查看Interix如何与Windows ACL交互的链接，重点是这些知识如何应用于其他Unix变体上的Samba文件系统。

这是指向已过时的 Solaris文档的链接，该文档描述了可调参数rstchown...

指示chown(2)系统调用的POSIX语义是否有效。

显然，如果参数设置为0...

...关闭POSIX语义会打开各种安全漏洞的可能性。这也使用户有可能将文件的所有权更改为另一个用户，并且在没有用户或系统管理员干预的情况下无法取回文件。

这样的选项不会使Solaris的POSIX一致性无效。只是它是一个选项就完全符合要求：

尽管符合POSIX.1-2008的所有实现都支持以下所有功能，但是可能存在依赖于系统或依赖文件系统的配置过程，可以删除或修改 这些功能中的任何一个或全部。如果需要严格遵守，则不应进行此类配置。

以下符号常量应定义为非-1的值。如果一个常数零值定义，应用程序应使用sysconf()，pathconf()或fpathconf()功能，或 getconf实用程序，以确定哪些特征是存在于系统中在该时间或所讨论的特定的路径名上。

_POSIX_CHOWN_RESTRICTED

使用chown()仅限于具有适当特权的进程，并且只能将文件的组ID更改为该进程的有效组ID或其补充组ID之一。

由于多种原因，chown()系统功能-由chown和chgrp实用程序进行的已记录的系统调用-被指定为失败。其中：

EACCES 在路径前缀的组件上拒绝搜索许可。

ELOOP 在解析路径参数期间遇到的符号链接中存在循环。

EPERM 有效的用户ID与文件的所有者不匹配，或者调用过程没有适当的特权，并且_POSIX_CHOWN_RESTRICTED表示需要这种特权。

但是，向非root用户授予权限修改权限的行为从来都不是Solaris独有的。在这个论坛帖子中有非常出色的文章（如果有些过时了），覆盖了Unix文件的权限，作者指出：

最初，Unix允许文件所有者放弃文件。文件的所有者可以将所有者更改为其他人。非root用户无法撤消此操作... BSD [稍后]chown从非root用户中删除... [部分原因是...]它实施了磁盘配额，该配额可能会限制一个磁盘空间。用户可能在文件系统中...顽皮的用户可以放弃大文件，以窥探配额。

今天，要说出非超级用户是否可以chown存储文件并不容易。Unix的许多版本都允许这两种行为...

另一个不错的-最近的邮件列表帖子对此进行了引用并继续：

大多数操作系统的默认设置chown仅限于root用户。出于安全考虑，人们一致认为应该保持这种方式。如果非root用户确实更改了文件的所有者，并且任何执行位均处于打开状态，则必须清除SUID和SGID位。这可能会发生，也可能不会发生root。

我认为最后一段很好。

该文章还提到CAP_CHOWN了在Linux上控制该功能（这只会影响POSIX_CHOWN_RESTRICTED行为）。还有一种CAP_FOWNER功能，在行为上有些不同。

正如您在2003年所指出的：

请注意，至少在HPUX上，即使您不是特权用户，也可以将文件的所有者更改为（root例如） ...

...取决于配置setprivgroup参数。

在非root用户可以操纵文件权限的任何情况下，都可以想到，正如您在问题中引用的基本原理中提到的那样，用户可能chown拥有该用户拥有的文件，以便该文件由另一个用户拥有。如果文件的组所有权和chowning用户的组不对齐，则用户将不再能够修改该文件。

在这种情况下chown ，然后 chgrp将失败，因为用户将不再有权限修改该文件的权限，而chown user:group-只要组是其中用户自己-会成功。

还有可能是许多其他小众的情况下可能导致类似的，其中可能包括目录粘性和/或setgid的位，文件系统和/或实现特定的访问控制列表。例如，该线程很有趣。数不清的排列方式远远超出了我自己的能力-这就是为什么这个答案被维基化的原因。如果您正在阅读此书，则认为它值得改进，并且您知道如何做 - 请这样做。

关于文件权限，树遍历和符号链接的各种可能影响，这里也有大量文档，它们在以下方面可能会导致与-R递归chown应用程序类似的失败：

从POSIX XRAT部分标题第三和第四域中：

通常，为文件层次结构遍历指定选项的用户希望在单个物理层次结构上进行操作，因此会忽略可能引用该层次结构外部文件的符号链接。例如，chown所有者文件是与指定-R选项的同一命令不同的操作。在此示例中，chown owner file此处描述了命令的行为，而chown -R在第三和第四域中描述了命令所有者文件的行为。

...存在默认遵循逻辑遍历的安全问题。从历史上看，命令chown -R用户文件对于超级用户而言是安全的，因为在更改文件所有权时setuid和setgid位会丢失。如果走是合乎逻辑的，则更改所有权将不再安全，因为用户可能已插入指向树中任何文件的符号链接。同样，这将需要在执行层次结构遍历的命令中添加一个选项，以使其不能通过符号链接间接进行，而进行递归遍历的历史脚本将立即成为安全问题。尽管这对于系统管理员来说主要是一个问题，但是最好不要为不同类别的用户使用不同的默认值。

...

在4.3 BSD中，chgrp在遍历树期间更改了符号链接的组，而不是目标。4.4 BSD中的符号链接没有所有者，组，模式或其他标准UNIX系统文件属性。

而从POSIX chgrp页面适当的还有这指向一个可能不完全-Recursive行动，或者至少什么用是：

System V和BSD版本使用不同的退出状态代码。一些实现使用退出状态作为发生的错误数量的计数。这种做法不可行，因为它可能会使有效退出状态值的范围溢出。标准开发人员选择仅通过指定0和> 0作为退出值来屏蔽这些内容。

假设1：确定是否chown成功的规则独立检查目标用户和组部分，即它们的形式user_condition(target_uid, other_environment_parameters) && group_condition(target_gid, other_environment_parameters)。

假设2：chown(file, -1, -1)成功。

假设3：确定是否chown成功的规则不取决于文件当前所属的组。

结论：如果chown(file, uid, gid)成功，那么也会chown(file, -1, gid) && chown(file, uid, -1)。

我不知道会违反任何这些假设的Unix变体，它们似乎很安全。

这个句子看起来很像委员会上的某个人说的，他们在经过数小时的辩论之后感到疲倦时，他们在ps电话的头上可能有多少选择权，或者秘书误判了，没有人在审查中被抓住。毕竟，还有其他充分的理由允许用户和组自动更改，包括POSIX原理中也提到的性能原因以及原子性（啊，如果只有一个调用来更改所有权和权限， ）。

假设3可能是错误的情况是在系统上，进程可以具有更改文件所有者的能力，但前提是他们具有文件的写许可权。虽然有些现实，但我不知道在这种情况下的任何系统。然后chgrp从既没有以root身份运行又没有以拥有该文件的用户身份运行的进程组成的组，可能会使该文件在以后无法访问chown。

对于递归调用，在某些情况下，如果单次通过将成功，则chgrp随后的整个过程与整个过程都chown将失败。这不是一个非常有说服力的参数，因为它涉及所有者没有遍历权限的目录，并且想要防止所有此类情况的应用程序无论如何都需要摆弄权限。但是，从技术上讲，它满足了此基本原理的条件。假设正在运行的进程具有有效的用户alice，有效的组staff，并且具有任意更改文件所有者的能力（不仅仅是为了放弃文件所有者；一些unix变体具有这种能力，尽管很少授予非root进程）。

$ ls -ld dir dir/file
d---rwx---  2 charlie  staff        1024 Apr  1  1970 dir
drw-rw----  2 charlie  staff          42 Apr  1  1970 file
$ chgrp -R students dir
$ chown -R bob dir
chown: dir: permission denied