id一次显示当前用户的 UID、主组 GID 和所有附加组。
用户与用户组
约 1098 字大约 4 分钟
2026-05-14
Linux 是天生的多用户系统。每个进程、每个文件都属于某个用户和某个组，系统靠这套身份体系决定“谁能做什么”。搞清楚用户、组、UID、GID 之间的关系，是看懂权限报错的第一步。
阅读导览
用户与用户组
理解 Linux 用 UID、GID 而不是名字判断身份，弄清主组与附加组的区别，掌握常用账户检查命令。
- 系统认 UID、GID，不认名字
- 主组与附加组的区别
- 服务账号与登录账号
- 改组后要重新登录才生效
命令速查
账户检查速查
先看清身份id username查指定用户的 UID 和组归属，排查权限问题常用。
getent passwd比直接 cat /etc/passwd 更全，能查到 LDAP 等外部账户。
groups username快速确认某用户是否在 sudo、docker 等关键组里。
系统认的是 UID，不是名字
你看到的是用户名 alice，但内核记录和判断身份用的是一个数字——UID。组同理，用 GID。/etc/passwd 里每行就是一个用户的映射：
alice:x:1001:1001:Alice:/home/alice:/bin/bash
# 名字 密码占位 UID GID 描述 家目录 登录Shell由此能解释一个现象：如果两个用户名共用同一个 UID，系统会把它们当成同一个身份——文件归属、权限判断全看 UID。root 之所以是 root，本质是因为它的 UID 是 0。
主组和附加组
一个用户有且只有一个主组（创建文件时，文件的组归属默认就是它），同时可以属于多个附加组：
id
# uid=1001(alice) gid=1001(alice) groups=1001(alice),27(sudo),998(docker)
# └─ 主组 └─ 附加组：能用 sudo、能操作 docker附加组是“授权”的常用手段：把用户加进 docker 组，他就能操作 Docker；加进 sudo（Debian 系）或 wheel（RHEL 系）组，他就能提权。
sudo usermod -aG docker alice # -aG：追加到附加组，别漏掉 ausermod 加组一定要带 -a
usermod -G docker alice 没有 -a，会把 alice 的附加组整个替换成只剩 docker——她原本在的 sudo 等组全没了。永远写成 -aG。另外，加组后需要重新登录（或开新会话）才生效，因为组信息是登录时加载进会话的，当前 Shell 不会自动刷新。
服务账号：不为登录而生
/etc/passwd 里你会看到一堆没见过的用户：www-data、nginx、postgres……这些是服务账号。它们存在的意义是：让服务以一个权限受限的身份运行，万一服务被攻破，攻击者拿到的也只是这个受限账号，而不是 root。
它们的特征通常是：UID 较小（系统保留区间）、登录 Shell 是 /usr/sbin/nologin 或 /bin/false（不允许交互登录）。不要给服务账号开登录权限，也不要用它们做日常操作。
常见误区
| 误区 | 更稳妥的做法 |
|---|---|
usermod -G 不带 -a 改附加组 | 一律用 -aG 追加，否则会清空原有附加组 |
| 加组后当前 Shell 立刻去用，发现没生效 | 组信息登录时加载，需重新登录或开新会话 |
| 随意修改系统用户的 UID、GID | 系统账号的 UID 牵连大量文件归属，不要乱动 |
| 给服务账号开登录权限图方便 | 服务账号就该 nologin，提权才是安全的初衷 |
实践清单
练习清单
- 1运行 `id`，逐字段说出你的 UID、主组、附加组分别是什么。
- 2`getent passwd` 翻一翻，找出几个登录 Shell 是 nologin 的服务账号。
- 3查一个用户 `groups <name>`，确认他在不在 sudo 或 docker 组。
- 4了解 `usermod -aG` 和 `usermod -G` 的区别——记住漏掉 a 的后果。
重点总结
要点回收
- 系统靠 UID、GID 判断身份，不靠用户名字符串；root 的本质是 UID 0。
- 用户有一个主组、可有多个附加组；附加组是常用的授权方式。
- usermod 加组用 -aG 且需重新登录；服务账号是为隔离权限而设，不用于登录。
版权所有
版权归属：Shuo Liu