chmod何时会失败？

在什么情况下会chmod失败？

我看了手册页，但它仅指定用法，没有详细介绍在什么情况下无法使用。

我认为在以下chmod情况下可以使用：

• 你是根
• 您拥有目标文件（并且正在设置普通模式位，即非粘性位，其他）

用户可以chmod用来更改对其具有组访问权限的文件的权限吗？它与读/写访问有关吗？

只有文件的所有者或root用户可以更改文件的权限。该文件或其父目录上的当前权限无关紧要¹。这是在POSIX中指定的：

应用程序应确保该过程的有效用户ID与文件的所有者匹配，或者该过程具有适当的特权才能执行此操作。

在大多数unices上，“适当的特权”是指以root用户身份运行。如果不满足这些条件，则chmod通常会失败EPERM，尽管允许其他行为，例如由于违反安全性而中止程序。

另外，某些unix变体具有特定于系统的授权或禁止方式chmod。例如，Linux具有功能（CAP_FOWNER），该功能允许进程更改文件的权限和其他元数据，而不管文件的所有者。

chmod即使文件存在，可以访问并且具有适当的所有者，也有其他原因可能导致失败。常见的文件包括只读文件系统或不支持FAT等权限的文件系统。较不常见的限制包括系统特定的限制，例如Linux ext2文件系统和后继文件的不可变属性。

¹ _{除非运行中的进程chmod必须能够访问该文件，否则该文件必须对包含该文件的目录及其经过的所有其他目录具有执行权限。}

所需的详细信息位于chmod（）系统调用的手册页中。代替man chmod使用man 2 chmod。 man chattr并且man 2 setxattr也会引起您的兴趣；chattr / setxattr（）设置的文件属性增强了chmod设置的传统Unix权限的行为。

根据UNIX标准，“该过程的有效用户ID必须与文件的所有者匹配，否则该过程必须具有适当的特权”。

有关适当特权的一点需要一些解释。在传统系统上，当进程的有效UID（在Linux上为文件系统UID，但请参见下文）为0 [即root]时，所有文件都允许使用chmod。

Linux有一个称为功能的系统，该CAP_FOWNER位控制chmod在所有文件上使用的能力。默认情况下，当execve()调用创建根进程时（通过执行setuid二进制文件或当实际UID为0时）或有效UID设置为0（在将其设置为非零值时删除），将授予所有功能。，并CAP_FOWNER在文件系统UID设置为0时启用了包括在内的一组功能（在将其设置为非零值时禁用）。阅读手册页以获取更多详细信息。

您提到了粘性位，但是省略了以下事实：用户不在分配给文件的组中时，他们也可能无法在文件上设置setgid位。在其他实现定义的情况下，setuid或setgid位也可以忽略。

用户可以使用chmod更改对其具有组访问权限的文件的权限吗？

你为什么不试试看呢？

$ touch foo
$ sudo install -o root -g $(id -gn) -m660 foo bar
$ ls -la bar
-rw-rw----  1 root  staff  0 Oct 21 21:33 bar
$ chmod g-w bar
chmod: bar: Operation not permitted
$ chmod g+x bar
chmod: bar: Operation not permitted