传统linux权限管理的局限性在于其不够精细、难以处理异常情况，且组管理复杂。1. 无法为特定用户或组外用户单独设置权限；2. 用户跨组权限管理复杂易出错；3. 难以处理权限限制的例外，如对组内个别成员或组外成员开放。acl通过setfacl和getfacl工具实现精细化控制，1. 可授予特定用户或组额外权限；2. 支持默认acl使新文件自动继承权限；3. 能删除特定用户的权限，同时mask机制确保权限上限，了传统ugo模型的不足。

在Linux系统里，管理多用户权限这件事，初看解决好像就是chmod、chown那几板斧，用户、组、其他人，读写执行。但说实话，真到了复杂的团队冲突或者特定应用场景，你会发现防火墙传统权限模型很快就捉襟见肘了。这个时候，ACL（Access Control）列表，访问控制列表）就有了一个可以让你精细到每一个文件、每一个用户的“瑞士军刀”。它不是替代传统权限，而是作为一种补充，让你赋予特定用户或组赋予比传统权限更指导、更灵活的访问控制。

要搞定Linux下的多用户权限，尤其是当传统的用户、组、其他（UGO）权限模式无法满足你的需求时，ACL是你的不二之选。首先，确保你的文件系统支持ACL。大多数现代Linux发行版默认都支持，比如ext4、XFS等。你可以通过查看文件系统的挂载选项来确认，比如mount | grep your_partition，看看有没有acl选项。如果没有，可能需要重新挂载在/etc/fstab或者中添加acl选项。

核心工具是setfacl和getfacl。setfacl用于设置ACL规则：给添加特定用户权限：比如，让用户dev_user文件project_report.txt有读写权限，即使他不在文件的所属组里：setfacl -m u：dev_user：rw project_report.txt登录后复制给特定组添加权限：如果qa_team组需要对test_data目录有读取和执行权限：setfacl -m g：qa_team：rx test_data/登录后删除复制ACL边界：不想让dev_user再访问project_report.txt了：setfacl -x u：dev_user project_report.txt登录后复制设置默认ACL： 这特别有用。如果你希望在某个目录下创建的新文件或目录自动继承某些ACL权限，可以设置默认ACL。例如，让shared_docs目录下创建新的文件和目录都默认允许协作者用户有读写器执行权限：setfacl -m d：u：collaborator：rwx shared_docs/登录后复制

这个d：导出就是“default”的意思。

getfacl用于查看ACL规则：查看文件或目录的ACL：getfacl project_report.txtgetfacl test_data/登录后复制

输出会清晰地列出用户、组、ACL边界，包括一个重要的掩码。

理解掩码非常关键。它不是一个独立的权限，而是ACL条目（非所有者、非所属组）的有效权限上限。任何ACL权限赋予的权限，都不能超过这个掩码所允许的范围。

如果mask是r--，即使你给某个用户设置了rwx，他实际上也只能有r--权限。传统Linux权限管理有哪些限制？

说实话，刚开始接触Linux权限的时候，觉得UGO（User，Group，其他）这套模型简直完美，简单粗暴又有效。但随着项目复杂度的增加，你会发现它很快就力不从心了。我记得有一次，一个项目目录需要让A组的所有成员通用读写器，同时B组的某个特定也成员能读写器，但B组的成员不行，而且这个B组的成员又不能加入A组。按照传统权限，你只能把文件设置为对“其他人”可写，但这显然太不安全了。

这就是传统权限的痛点：它不够“细”。“非此即彼”的困境：一个文件或目录，或者属于某个用户，或者属于某个组，或者就是“其他人”。你很难为“除了该组之外的某个特定用户”或者“除了这个用户之外的某个特定组”设置权限。组的限制：虽然你可以通过创建不同的组来管理权限，但如果一个用户需要同时访问多个不同组的资源，并且在每个资源上的权限不太一样，那么这个用户的组管理就会变得异常复杂，甚至会因为主组和附加组的切换问题导致权限失效。 缺乏异常处理：传统权限模型很难处理“例外情况”。比如，一个目录默认对某个组开放，但其中某个文件需要对组内某个成员开放，或者对组外某个成员开放，这在UGO模型下几乎是不可能完成的任务，除非你把文件复制出来，或者改变其主人/组，但又会带来新的的管理混乱。这些，正是ACL诞生的原因，它完成了UGO模型在精细化权限控制上的空白。如何实战应用ACL进行精细化权限控制？

实战ACL，我觉得最重要的是理解setfacl的各种参数以及mask的说明。这玩意儿用起来，让你对文件权限的掌控力瞬间提升好几档次。

我们来几个具体的场景：

场景一：让一个非所有者、非所属组的用户拥有特定权限。假设你有一个配置文件/etc/my_app/config.conf，它的全部者是root：root，权限是640（rw-r-----）。现在，你希望用户app_admin能够修改这个文件，但又不希望把app_admin加到root组，也不想把文件权限改成660（因为那会影响到root组里的其他用户）。#赋予用户app_admin对config.conf的读写权限 setfacl -m u：app_admin：rw /etc/my_app/config.conf登录后复制

然后用getfacl查看：getfacl /etc/my_app/config.conf# file： /etc/my_app/config.conf# Owner： root# group： root# user：：rw-# group：：r--# other：：---# user：app_admin：rw- #这行就是ACL添加的权限# mask：：rw- #注意这里的mask，它决定了app_admin实际能够获得的最高权限登录后复制

你会发现，文件的传统权限显示会多一个号，比如-rw-r----- ，这表示该文件应用了ACL。

场景二：给一个目录设置默认ACL，让新创建的文件自动继承权限。这是一个非常常见的需求，尤其是在共享目录或者项目协作目录里。

比如说，团队的共享工作目录是/data/shared_workspace，你希望都在这个目录下创建的新文件和新目录，自动让dev_group组有读写执行权限，同时让auditor用户有复杂权限。#首先，给目录自己设置ACLsetfacl -m g：dev_group：rwx /data/shared_workspacesetfacl -m u：auditor：r-x /data/shared_workspace#一起，设置默认ACLsetfacl -m d：g：dev_group：rwx /data/shared_workspacesetfacl -m d：u：auditor：r-x /data/shared_workspace登录后复制

现在，在/data/shared_workspace里创建任何新的文件或目录，它们都会自动带上这些ACL规则。cd /data/shared_workspacetouch new_file.txtmkdir new_foldergetfacl new_file.txtgetfacl new_folder登录后复制

你会看到new_file.txt和new_folder都继承了dev_group和auditor的ACL权限。

三个场景：删除特定用户的ACL权限。当一个项目成员退出或者角色变更，需要快速撤销其对某个目录或文件的ACL权限时：

以上就是Linux如何设置多用户权限？_LinuxACL权限管理实战的详细内容，更多请关注乐哥常识网相关其他文章！