1.1 UID与GID：用户和组的唯一标识#

Linux系统不通过用户名识别用户，而是通过数字ID来识别：

• UID (User ID)：用户唯一标识号，每个用户拥有一个全局唯一的UID。
• GID (Group ID)：用户组唯一标识号，每个组拥有一个全局唯一的GID。

NOTE核心配置文件

• 用户名和UID的映射关系存储在 [/etc/passwd] 密级文件中。
• 用户密码哈希值存储在处于极高权限读写控制的 [/etc/shadow] 文件中。
• 组名和GID的映射关系存储在 /etc/group 文件中。 ::

1.2 /etc/passwd：揭秘用户账户的核心档案#

在 Linux 中，所有用户的基本信息（除了密码的真实哈希值）都以明文形式公开存放在 /etc/passwd 文件中。理解这个文件的结构，是排查用户问题的基本功。

我们可以使用 cat 或 head 查看其中的内容：

1
[root@server ~]# head -n 3 /etc/passwd
2
root:x:0:0:root:/root:/bin/bash
3
bin:x:1:1:bin:/bin:/sbin/nologin
4
testuser:x:1000:1000:Test Account:/home/testuser:/bin/bash

每一行代表一个用户，通过冒号 : 分隔成了 7 个关键字段。以 testuser:x:1000:1000:Test Account:/home/testuser:/bin/bash 为例，字段含义拆解如下：

1.3 Linux用户分类#

根据UID范围和权限不同，Linux用户分为三类：

[!WARNING] 发行版差异注意 Ubuntu 22.04 LTS 及更新的发行版，普通用户UID从 1000 开始（早期部分版本为 500+）。跨发行版迁移数据时需警惕UID错位导致权限丢失的问题。

1.4 用户组的概念#

用户组是具有相同权限的用户集合，用于简化权限管理：

• 主组 (primary group)：每个用户必须且只能有一个主组，创建用户时默认创建同名主组。
• 附加组 (supplementary group)：用户可以加入0个或多个附加组，继承附加组的所有权限。

2.1 创建与删除用户：useradd & userdel#

1
# 1. 常规操作：创建普通用户，自动创建家目录，并指定 bash 为解释器（最常用）
2
useradd -m -s /bin/bash testuser
3

4
# 2. 复合操作：创建用户时，直接指定它的主组(-g)和多个附加组(-G)
5
# 场景：新入职开发，属于 developers 组，同时需要 nginx 和 wheel 的权限
6
useradd -m -s /bin/bash -g developers -G wheel,nginx devuser
7

8
# 3. 创建系统虚拟用户（极其重要）
9
# 场景：为了运行 Nginx 或 MySQL 建立的账号。
10
# 必须加上 -r（系统账号）、-s /sbin/nologin（禁止登录）、不需要 -m（不需要家目录）
11
useradd -r -s /sbin/nologin mysql

1
# 1. 软删除：仅删除系统账号，但保留 /home/testuser 家目录里的数据
2
# 场景：员工离职，账号回收，但他的工作文件需要留给主管审查交接
3
userdel testuser
4

5
# 2. 硬删除：彻底删除账号，并强制删掉对应的家目录和本地邮件池
6
# 场景：交接完毕，彻底清理系统垃圾
7
userdel -r testuser

2.2 密码安全生命周期：passwd#

passwd 不仅仅是用来“改密码”的，它更是系统管理员控制账户安全周期的利器。

常用参数速查表：

1
# 1. 修改密码：root 可以改任何人的，普通用户直接敲 passwd 只能改自己的
2
passwd testuser
3

4
# 2. 强制下次登录重置密码（极度推荐！）
5
# 场景：管理员统一为新员工建号并设置初始密码（如 123456），
6
# 执行此命令后，新员工第一次登录必须马上修改密码，免去安全隐患
7
passwd -e testuser
8

9
# 3. 锁定异常账户（防爆破）
10
# 场景：发现 testuser 正在被频繁爆破密码，紧急锁定，让他无法用密码登录
11
passwd -l testuser
12

13
# 4. 解锁账户
14
passwd -u testuser
15

16
# 5. 查看账户的密码状态（LK=锁定，PS=正常，NP=无密码）
17
passwd -S testuser

CAUTION危险操作

绝对禁止使用 passwd -d 用户名 清空密码。此举将极大降低系统防御等级，造成任意人员零门槛提权隐患！ ::

2.3 修改用户属性：usermod#

当员工转岗，或者需要临时提权、封禁时，usermod 是修改已存在用户属性的神器。

常用参数速查表：

1
# 1. 将用户追加到新的附加组
2
# 场景：让普通用户获得 sudo 提权资格（CentOS系加到 wheel，Ubuntu系加到 sudo）
3
usermod -aG wheel testuser
4

5
# 2. 封禁登录：修改用户的默认 Shell
6
# 场景：外包人员项目结束，保留数据但不允许再登录系统
7
usermod -s /sbin/nologin testuser
8

9
# 3. 账号更名：平滑变更为新名字，原有的 UID、GID、家目录统统不变
10
# 场景：外包转正，从 v-zhangsan 改名为 zhangsan
11
usermod -l newuser olduser
12

13
# 4. 修改用户的主组（很少用，通常只改附加组）
14
usermod -g newgroup testuser

TIP血泪教训

在赋予用户新的附加组时，必须且永远使用 -aG（Append + Group）。如果漏写 a（仅使用 -G），将会直接清空并覆盖该用户原有的所有附加组！无数新手因为漏掉一个 a 导致用户丢失了原本的文件访问权限。 ::

2.4 用户组的创建与修改：groupadd 等#

权限控制的基石是 RBAC（基于角色的访问控制），在 Linux 中体现为**“组管理”**。我们应该先建组、给组赋权，再把用户拉进组里。

组管理核心命令与参数速查表：

1
# 1. 创建一个新用户组（如研发组、运维组）
2
groupadd developers
3

4
# 2. 创建系统级的虚拟用户组（配合系统虚拟账户使用）
5
groupadd -r mysql
6

7
# 3. 修改组名（将 developers 平滑变更为 devops，原有的 GID 不变）
8
groupmod -n devops developers
9

10
# 4. 将用户移出某个附加组（使用 gpasswd 命令）
11
# 场景：实习生结束轮岗，剥夺他的高级运维权限（移出 wheel 组）
12
gpasswd -d testuser wheel
13

14
# 5. 删除用户组
15
# 注意：如果要删除的组是某个用户的主组，则必须先删用户或修改其主组，否则无法删除
16
groupdel devops

2.5 查看与切换身份 (su 与查询命令)#

日常排错时，我们需要经常查看用户身份，或者切换身份去验证权限。这里面的参数携带尤为关键。

切换身份参数速查表 (su)：

1
# 1. 查看指定用户的身份信息（UID、主组、所有附加组）
2
# 场景：排查某人为什么打不开某个文件，先看他在不在对应的组里
3
id testuser
4

5
# 2. 抓内鬼：查看当前有哪些人在线，正在执行什么命令
6
w
7
who
8

9
# 3. 切换身份（切记区分带减号和不带减号的区别）
10
# 【强烈推荐】完全切换（需要密码，且重新加载该用户的完整环境变量，像重新登录一样）
11
su - testuser
12

13
# 【不推荐】仅切换身份（环境变量仍残留上一个用户的配置，极易引发命令找不到、路径错乱）
8 collapsed lines
14
su testuser
15

16
# 4. 免切用户执行一次性指令（运维最爱）
17
# 场景：在 root 的定时任务 (crontab) 中，以 testuser 的身份去跑脚本
18
su - testuser -c "sh /home/testuser/backup.sh"
19

20
# 5. 企业绝活：批量枚举系统所有可登录的真人账户（UID >= 1000 且 Shell 正常）
21
awk -F: '$3 >= 1000 && $7 != "/sbin/nologin" && $7 != "/bin/false" {print $1}' /etc/passwd

3.1 为什么必须用 visudo？#

配置 sudo 权限就是修改 /etc/sudoers 文件。

IMPORTANT生死攸关的规范

绝对禁止使用 vim /etc/sudoers 直接修改！必须使用 visudo 命令。 visudo 会在保存退出时自动进行语法校验。如果你用 vim 写错了一个符号，会导致全公司所有人都无法使用 sudo，连 root 都切不进去，系统直接“变砖”！ ::

3.2 配置文件核心语法拆解#

用 visudo 打开配置后，你会看到类似这样的配置格式：

1
root    ALL=(ALL:ALL) ALL

这五个部分的含义决定了权限的分配逻辑：

1. 谁来执行：root（可以是用户名，也可以是 %组名）
2. 在哪里执行：第一个 ALL（表示可以在任何主机/网络上执行）
3. 以谁的身份：括号里的第一个 ALL（表示可以切换成系统里的任何用户，通常是 root）
4. 以什么组的身份：括号里的第二个 ALL（可省略，表示任何用户组）
5. 能执行什么命令：最后一个 ALL（表示允许执行所有命令，必须写命令的绝对路径）

3.3 企业级场景配置实战#

在实际企业中，我们不会给每个人都分配 ALL 权限，而是会根据岗位职责进行“精细化切割”。

1
# 允许 wheel 组的所有成员执行任何命令，并且不需要输入密码
2
%wheel ALL=(ALL) NOPASSWD: ALL

1
# 允许 devuser 用户免密执行重启 docker 服务和操作 docker 容器的命令
2
# 注意：命令必须写绝对路径！
3
devuser ALL=(ALL) NOPASSWD: /usr/bin/systemctl restart docker, /usr/bin/docker *

1
# 允许 opsadmin 执行所有命令，但禁止切换到root、禁止改root密码、禁止改sudoers文件
2
opsadmin ALL=(ALL) ALL, !/usr/bin/su, !/usr/bin/passwd root, !/usr/sbin/visudo

3.4 进阶技巧：使用命令别名 (Cmnd_Alias) 简化配置#

当系统里有几十个开发人员、十几个服务需要管理时，一行行写绝对路径会让人崩溃。/etc/sudoers 支持使用别名来将命令和人员打包。

1
# 1. 定义用户别名（把张三、李四打包成 WEB_ADMINS）
2
User_Alias WEB_ADMINS = zhangsan, lisi
3

4
# 2. 定义命令别名（把所有和 Nginx 相关的命令打包成 NGINX_CMDS）
5
Cmnd_Alias NGINX_CMDS = /usr/bin/systemctl start nginx, /usr/bin/systemctl stop nginx, /usr/bin/systemctl reload nginx
6

7
# 3. 将别名绑定：允许 WEB_ADMINS 组的人免密执行 NGINX_CMDS 里的命令
8
WEB_ADMINS ALL=(ALL) NOPASSWD: NGINX_CMDS

TIP配置分离的最佳实践

在现代 Linux 中，我们通常不直接修改 /etc/sudoers 主文件。而是会在 /etc/sudoers.d/ 目录下，为每个项目或团队新建一个独立的配置文件（例如 visudo -f /etc/sudoers.d/dev_team）。这样不仅方便管理，也避免了多人同时修改主文件引发冲突。 ::

4.1 符号与数字八进制转换阵列#

Linux文件将权限拆分为所有者 (u)、所属组 (g) 和其他用户 (o) 三维控制体。

4.2 赋权操作：chmod 与 chown#

在 Linux 中，权限的修改分为两部分：改权限（谁能干嘛）用 chmod，改归属（这是谁的）用 chown。

1
# 【经典组合】所有者具有完全读写，组及其他仅可读
2
chmod 644 config.yml
3

4
# 【追加执行权限】（常用于自己刚写完的脚本）
5
chmod +x script.sh  # 等价于 chmod a+x (给所有人加执行权限)
6
chmod u+x script.sh # 只给所有者自己加执行权限
7

8
# 【基线规范】递归分离化授权：网站目录赋755，文件降权至644（防止黑客上传的图片被当成木马执行）
9
find /var/www/html -type d -exec chmod 755 {} \;
10
find /var/www/html -type f -exec chmod 644 {} \;

1
# 1. 仅修改文件所有者为 testuser
2
chown testuser deployment.sh
3

4
# 2. 仅修改文件所属组为 developers（前面留空只写冒号和组名）
5
chown :developers deployment.sh
6

7
# 3. 同时修改所有者为 testuser，且所属组变更为 developers
8
chown testuser:developers deployment.sh
9

10
# 4. 【核心参数 -R】深度易主：递归转移整个层级目录属权（运维最高频操作）
11
# 场景：你用 root 拉取了最新的前端代码放到 /var/www/html，
12
# 必须把整个文件夹移交给 nginx 账号，否则网页会报 403 Forbidden
13
chown -R nginx:nginx /var/www/html/

4.3 高级进阶：特殊权限（SUID/SGID/SBIT）#

除了普通的 rwx，Linux 还有三个高级权限位，它们能打破常规的安全壁垒：

1. SUID (4)：只能作用于可执行的二进制程序。普通用户在执行这个程序时，会临时获得程序所有者的权限。最经典的例子是 /usr/bin/passwd，普通用户能靠它修改 /etc/shadow 就是因为 SUID。
2. SGID (2)：作用于目录时，任何人在该目录下创建的新文件，所属组都会自动继承该目录的所属组。（常用于团队共享协作目录）。
3. SBIT 粘滞位 (1)：只能作用于目录。在该目录下，用户只能删除自己创建的文件，不能删除别人的文件。最经典的例子是公共临时目录 /tmp（权限是 1777）。

1
# 赋予 SUID 权限（数字法在原有的三位前加 4）
2
chmod 4755 /usr/local/bin/myapp
3
# 赋予 SGID 权限
4
chmod 2775 /shared_data/
5
# 赋予 SBIT 粘滞位
6
chmod 1777 /company_tmp/

4.4 权限防护盾：默认掩码 Umask 控制#

为什么我们 touch 一个新文件，它的默认权限是 644，而 mkdir 一个新目录，默认权限是 755？这就是被 umask 拦截处理后的结果。

• 新建文件的默认最高基底权限为 666（系统禁止文件一创建就有执行权限）。
• 新建目录的默认最高基底权限为 777。
• 最终生成的权限值 = 基底基数 - umask。

系统默认的 umask 是 022，所以：

• 文件：666 - 022 = 644
• 目录：777 - 022 = 755

1
# 在全局环境拦截高危文件建立（针对协同配合进行微调）
2
if [ "$UID" -gt 199 ] && [ "`/usr/bin/id -gn`" = "`/usr/bin/id -un`" ]; then
3
    umask 022
4
    umask 002  # 改为002，协同组创建的文件权限将自动变为664，目录变为775，方便同组人互相修改
5
fi