所以我试图理解 Linux 中组和权限的概念，并且完全困惑。在我的笔记本电脑上，我是唯一用户，因此是超级用户，我了解更改文本文件的文件权限 (chmod +x) 以使其可执行，或更改读写权限 (chmod + /- rw)
但我并没有真正理解组的概念。从我收集到的一个组只是一群用户。（但这是否意味着用户可以属于多个组？）据我所知，组基本上是为了更容易地rwx为一群用户（即组）设置/取消设置权限。
但现在在这个网站上，作者说：
Linux 中的权限分为三个级别：所有者、组和其他。所有者是拥有文件/文件夹的用户，该组包括文件所在组中的其他用户，而 other 仅代表不是所有者或组中的所有其他用户。
这是否意味着除了具有所有者（即创建文件的人的用户 ID）的文件之外，该文件还有一个“组所有者”？这个组通常是文件所有者所属的组之一吗？
如果我有三组A，B，C我的系统上，并要设置权限 rw-，-wx，r-x分别在系统上？
提出上述问题很可能表明我对 Unix 中的“组”和“组权限”的理解是有缺陷的。
我试过阅读一堆文章，但我似乎缺少理解组和组许可概念的基本知识。有人可以给我一个简洁的解释或向我推荐一些关于这个主题的更清晰的文章吗？
use*_*686 46
但我并没有真正理解组的概念。从我收集到的一个组只是一群用户。（但这是否意味着用户可以属于多个组？）
是的，是的。
据我所知，组基本上是为了更容易地为一群用户（即组）设置/取消设置 rwx 权限批发。
当组需要访问分散在系统中的许多文件或文件夹时，它使设置权限更容易的一种方法是。
例如，每当有新用户加入时，您都需要一个一个地查找所有这些文件，并尝试猜测诸如“如果用户 A、B、C 具有访问权限，则应添加用户 D”之类的内容。但是，如果这些权限只是列出了一个组名，那么您根本不需要更新它们——相反，您只需将用户添加到一个组中，就完成了。
（它不仅限于文件权限 - 一些系统服务也可能被配置为授予组而不是单个用户的访问权限，具有与此处相同的优点。）
这是否意味着除了具有所有者（即创建文件的人的用户 ID）的文件之外，该文件还有一个“组所有者”？这个组通常是文件所有者所属的组之一吗？
是的。每个用户都有一个“主要组”，新创建的文件属于该组。但是，即使是非 root 用户也可以使用 chown/chgrp 将他们自己的文件重新分配给他们当前所属的任何组。
（有一个例外：如果目录设置了“setgid”位，则其中新创建的文件将继承目录的组，而不是创建者的组。这更接近于 Windows NTFS 默认的工作方式。）
当然，当文件一次只能有一个组时，这个“组所有者”系统有点限制。请参阅下一节。
如果我的系统上有 A、B、C 三个组，并且想在系统上分别设置权限 rw-、-wx、rx 怎么办？
然后您使用另一个称为“ACL”（访问控制列表）的功能，顾名思义，它允许您指定要授予访问权限的任意用户和组列表。
Linux 支持 POSIX ACL 格式，这主要是对现有模型的直接扩展。也就是说，如果您首先将现有权限重写为：
user::rwx, group::r-x, other::---
现在您可以使用setfacl或chacl将您的三个附加组添加为：
group:Family:rw-, group:Friends:-wx, group:Coworkers:r-x
避免混淆的注意事项： POSIX ACL 尝试尽可能地与传统的 chmod 保持兼容，但这会导致一个令人惊讶的特性。一旦您将 ACL 添加到文件中，“组”字段ls -l将开始显示称为“掩码”的内容，并且类似的命令chmod g-w将拒绝对所有 ACL 条目的写访问，而不仅仅是对“所有者组”的写访问。
如果 Linux 甚至 Unix 可以只使用 ACL，为什么要使用“所有者/组/其他”分类？这是因为这种简单的分类早于 ACL 支持几十年。
Unix 最初采用的是简单的方法，就像当时大多数其他操作系统所做的那样——要么是由于磁盘空间限制（权限位只适合两个字节），和/或故意的设计决策（Multics 当时可能有精心设计的 ACL） ，但 Unix 中的很多东西都被有意简化了）。
最终 API 变得一成不变——可以添加新的 API，但无法更改现有的“chmod”，因为程序已经期望它以某种方式工作。（即使在添加了 ACL 之后，OpenVMS 也必须保持其类似的权限位系统。）
除此之外，不幸的是，它是所有类 Unix 操作系统之间唯一的系统交叉兼容。其他一些 Unix（例如 FreeBSD、Solaris）可能使用完全不同的 ACL 格式，而其他一些（OpenBSD）则根本不支持 ACL。也可以与 Windows 进行比较，Windows 中的所有文件保护都是基于 ACL 的。
fil*_*den 17
的Linux / Unix组的概念可以被混淆。但让我们试着解开它。
文件和目录同时具有所有者和组（或您所说的“组所有者”）。它们还有三组rwx权限位，一组用于用户，一组用于组，一组用于其他。此外，他们还有三个权限：setuid、setgid 和sticky。文件或目录的用户和组在内部存储为 UID 和 GID，它们是无符号整数，用作用户和组的内部标识符。
系统中的用户有一个 UID 和一个 GID（通常在/etc/passwd文件中设置），该文件中的 GID 设置用于指示用户的主要组。此外，一个用户可能属于多个组（通常在/etc/group文件中配置，该文件列出了系统中每个组的其他用户。）
您可以使用该id命令检查用户的 UID、GID、主要组和其他组，该命令将列出运行该命令的用户的所有这些信息。
当您尝试访问文件或目录时，系统将尝试根据权限位验证您的访问权限。特别是，它将首先查看是否使用用户、组或其他位。如果您的 UID 与访问文件的用户的 UID 完全匹配，则将使用“用户”位。对于组，如果您的主要组与文件组匹配，或者如果任何附加组（如 报告的id）与该组匹配，则将使用“组”位。否则，如果这些都不匹配，则将使用“其他”位。
文件权限的含义相当简单，r意味着您可以打开文件进行读取，w意味着您可以打开该文件进行写入（从而修改其内容），并x意味着您可以将此文件作为可执行文件（无论是二进制文件还是脚本）运行.)
对于目录，它有点微妙。r意味着您可以列出该目录中的文件（例如，使用ls /path/to/dir），w意味着您可以在该目录中创建新文件（或从该目录中删除现有文件。）但是您需要x能够访问该目录中的任何文件，如果您没有x目录，则无法cd访问该目录，也无法真正打开该目录中的文件，即使您知道它们存在。（这允许古怪的设置，其中有r但没有x，你可以列出文件名但你不能打开任何文件，而有x但没有r 只有当您已经知道文件名称时才能打开目录中的文件，因为您无法列出目录中的文件名。）
假设您有权在目录中创建新文件，您创建的新文件将以您的用户作为所有者，默认情况下，它将以您的主要组作为其“组所有者”。但情况并非总是如此！
还记得我之前提到过 setgid 位吗？好吧，如果一个目录设置了 setgid 投标（您可以使用 设置它chmod g+s /path/to/dir），那么在该目录中创建的新文件将继承该目录本身的组，而不是创建它的用户的主要组。此外，如果您在这样一个启用 setgid 的目录下创建一个新的子目录，该子目录也将启用 setgid 位。（为了保留整个子树的组继承属性，这是必要的。）
这个 setgid 目录技术对于实现共享目录非常有用。我们很快就会谈到这一点。
另一个有趣的注意事项是 BSD 家族中的 Unix 系统（例如 FreeBSD、NetBSD、OpenBSD） 总是表现为在目录中设置了 setgid 位。这样，用户的主要组就没有那么有意义了，因为在文件创建期间作为该组通常是该组最明显的特征。
另一个有趣的概念是“umask”，它是一组在创建新文件或目录时被“屏蔽”的位。您可以使用umask命令在 shell 中检查您的 umask，您也可以使用该命令和参数来修改当前的 umask。典型值是umask 002，umask 022，umask 027，等。
umask 中的位是指位rwx，三个八进制数字映射到权限模式下的用户、组和其他位。所以umask 002将保留用户和组的所有位（0 表示没有屏蔽），而他们将阻止w其他位（2 是w.）他们将保持文件用户和组可写，但只能由其他人读取。umask 027另一方面，只有用户可写，只能可读/可执行但不能按组写，其他人不能访问（7 表示屏蔽所有rwx.）
在umask使用每次创建新文件的时间。应用程序通常以最自由的方式指定他们想要的权限，以便 umask 可以将其限制为更实际的权限。例如，普通应用程序会要求创建具有 0666 ( rw-rw-rw-) 权限的文件，期望 umask 至少会删除全局可写位。rwxrwxrwx假设相同，通常会使用 0777 ( )创建目录。
那么我们怎样才能把这一切放在一起呢？
基于 Red Hat 的 Linux 发行版（例如 RHEL、CentOS 和 Fedora）通常使用的设置非常灵活，值得研究。
对于创建的每个用户，也会创建一个同名组（通常具有与用户的 UID 匹配的 GID），并且该组被设置为该用户的主要组。该组旨在仅包含具有相同名称的用户。所以我的用户的文件通常创建为filbranden:filbranden，我自己的主要组控制组权限位。
由于组本质上与用户本身相同，因此umask设置为 002，这意味着默认情况下所有文件和目录都将是组可写的。
那么如何锁定目录以使其成为私有的呢？简单，只需从顶级目录中删除“其他”的权限位。例如，如果我使用chmod 770 ~（或者700也很好，770因为主要组是我自己的），其他用户将无法访问我的主目录下的任何文件。里面的文件已经读取或执行了“其他”的x位并不重要，因为缺少顶级目录本身的位意味着它们将永远无法遍历那个。
那么如何实现共享目录呢？简单的。首先创建一个组并将所有打算在该项目上进行协作的用户添加到该组。接下来，为该项目创建一个（或多个）目录。将目录的“组所有者”设置为您刚刚创建的组。最后，在这些目录上启用 setgid 位。该组的所有成员都可以在这些目录中创建文件。由于它们都有umask 002，因此它们创建的文件将是可组写的。并且由于顶级目录中的 setgid 位，所有文件都将由共享组（而不是每个用户的主要组）拥有。这意味着该组中的用户将能够修改由其他成员创建的文件组的，因为他们将拥有对这些文件的写权限。
这些共享目录可以是世界可读的（通过在顶级目录中保留“其他”的r和x权限），或者可以是组私有的（通过删除这些权限。）
这就是它的要点。Unix/Linux 权限通常如何工作以及它们为何以这种方式工作的基本原理。
当然，有很多警告。许多这些设置（例如umask）存在于不同的会话中，并且它们可能不同步。将用户添加到组意味着他们通常需要再次登录才能使更改生效。在启用 setgid-bit 的目录中创建文件会导致该目录的组被继承，将现有文件移动到该目录中通常不会更改所有权（因此您最终可能会在组共享中获得不可修改的文件）组的其他成员。）关于删除文件的语义也可能有些棘手。
现代 Unix/Linux 系统保留了用户、组和文件所有权背后的所有逻辑。但它们通常还包括强制执行权限的其他机制，例如扩展文件 ACL，它可以更精细地允许对目录树的读/写访问，并且不会遇到上面列出的基本权限的许多问题。
| 归档时间： |
|
| 查看次数： |
4910 次 |
| 最近记录： |