Linux多用户权限设置详解

还在为Linux多用户权限管理头疼吗？传统UGO权限模型在复杂场景下捉襟见肘，无法满足精细化需求？本文为你带来一份详尽的Linux多用户权限设置教程，重点讲解如何利用ACL（访问控制列表）突破传统权限的局限。ACL作为UGO模型的补充，通过`setfacl`和`getfacl`工具，实现对特定用户或组的精细权限控制，包括赋予额外权限、设置默认ACL使新文件自动继承权限，以及移除特定用户权限等功能。文章将深入探讨ACL的实战应用，例如让非所有者用户拥有特定权限、为共享目录设置默认ACL，以及快速撤销用户权限等场景，助你轻松应对复杂的团队协作和特定应用需求，提升Linux权限管理水平，确保系统安全。

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

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

要搞定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目录下新创建的文件和目录都默认允许collaborator用户有读写执行权限：

  setfacl -m d:u:collaborator:rwx shared_docs/

  这个d:前缀就是“default”的意思。

getfacl用于查看ACL规则：

• 查看文件或目录的ACL：

  getfacl project_report.txt
  getfacl test_data/

  输出会清晰地列出用户、组、以及ACL条目，包括一个重要的mask。

理解mask非常关键。它不是一个独立的权限，而是ACL条目（非所有者、非所属组）的有效权限上限。任何ACL条目赋予的权限，都不能超过这个mask所允许的范围。如果mask是r--，即使你给某个用户设置了rwx，他实际也只能有r--权限。

传统Linux权限管理有哪些局限性？

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

这就是传统权限的痛点：它不够“细”。

1. “非此即彼”的困境： 一个文件或目录，要么属于某个用户，要么属于某个组，要么就是“其他人”。你很难为“除了这个组之外的某个特定用户”或者“除了这个用户之外的某个特定组”设置权限。
2. 组的限制： 虽然你可以通过创建不同的组来管理权限，但如果一个用户需要同时访问多个不同组的资源，并且在每个资源上的权限还不一样，那么这个用户的组管理就会变得异常复杂，甚至会因为主组和附加组的切换问题导致权限失效。
3. 缺乏例外处理： 传统权限模型很难处理“例外情况”。比如，一个目录默认对某个组开放，但其中某个文件需要对组内某个成员禁用，或者对组外某个成员开放，这在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用户有只读权限。

# 首先，给目录本身设置ACL
setfacl -m g:dev_group:rwx /data/shared_workspace
setfacl -m u:auditor:r-x /data/shared_workspace

# 接着，设置默认ACL
setfacl -m d:g:dev_group:rwx /data/shared_workspace
setfacl -m d:u:auditor:r-x /data/shared_workspace

现在，在/data/shared_workspace里创建任何新的文件或目录，它们都会自动带上这些ACL规则。

cd /data/shared_workspace
touch new_file.txt
mkdir new_folder
getfacl new_file.txt
getfacl new_folder

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

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

今天带大家了解了的相关知识，希望对你有所帮助；关于文章的技术知识我们会一点点深入介绍，欢迎大家关注golang学习网公众号，一起学习编程~