Linux 系统中的用户、用户组以及权限管理:从入门到搞懂,其实没那么绕

很多刚开始学习 Linux 的朋友，都会被权限这块知识绕得晕头转向：一会是用户，一会是用户组，rwx、chmod、chown、root 这些概念堆在一起，看着就让人头疼。

但真正进入职场做技术开发或运维之后你就会发现：Linux 权限管理，其实是整个系统安全的核心。

因为 Linux 从设计之初就是一个「多用户系统」——简单来说就是，很多人可以同时登录使用同一台服务器：运维要维护系统、开发要部署项目、DBA 要管理数据库、测试要跑用例，甚至各个应用程序（Nginx、MySQL 这些服务）本身也需要独立的身份运行。

这么多不同身份的主体共用一台机器，自然要回答几个核心问题：

• 谁能看这个文件？
• 谁能修改这个文件？
• 谁能删除这个文件？
• 谁能执行这个程序？

这就是权限管理存在的意义，今天我们就把这块知识彻底捋清楚，读完你就能完全搞懂 Linux 的权限体系了。

你可以把 Linux 的用户简单理解成：系统中的身份标识。

比如你远程登录一台 Linux 服务器，通常会敲这么一行命令：

bash
ssh root@192.168.1.10

这里的 root，就是你登录系统使用的用户身份。系统通过这个身份，判断你能做什么、不能做什么。

Linux 中每个用户都会对应一组核心信息：

• 用户名：方便人类记忆的名称，比如 root、dev
• 密码：验证身份的凭证
• UID（用户ID）：系统内部识别用户的唯一数字ID，比用户名更底层
• 家目录：用户登录后默认所在的目录，普通用户一般是 /home/用户名，root 是 /root
• Shell：用户登录后默认使用的命令解释器，一般是 /bin/bash

系统就是靠这些信息来识别「你是谁」，进而给你分配对应的权限。

Linux 中的用户不是千篇一律的，按照用途可以分成三类，每类的权限边界都非常清晰。

1、root 用户：权限最大的系统管理员

root 是 Linux 中权限最大的用户，相当于 Windows 里的 Administrator，几乎可以做任何事情：删除任意文件、修改系统核心配置、安装卸载软件、甚至直接关闭整个系统。

root 最大的特点就是：几乎不受任何权限限制。

也正因为如此，工作中最危险的操作通常都是 root 执行的，比如流传甚广的删库命令：

bash
rm -rf /

如果用 root 执行这条命令，理论上会直接把整个系统文件全部删除，直接造成生产事故。所以日常工作中，除非必要，一般不建议直接用 root 登录操作。

2、普通用户：受限的登录用户

普通用户就是我们日常登录使用的用户，比如给开发创建的 dev、给测试创建的 test，都属于普通用户。

这类用户的权限是受限的：通常只能操作自己家目录下的文件，只能使用系统允许的命令，只能访问开放给普通用户的资源。这种设计本身就是为了安全——避免普通用户误操作影响整个系统。

比如你用普通用户去删除系统核心文件 /etc/passwd，系统会直接提示你权限不足，这就是权限设计在保护系统。

3、系统用户：服务专用的运行身份

很多人会忽略这类用户：大部分后台服务启动的时候，都会自动创建一个专用的系统用户，比如我们常用的：

bash
nginxmysqlrediswww-data

为什么服务需要单独的用户？这其实是 Linux 安全设计的精髓：不同服务用不同的独立身份运行，权限隔离。

如果所有服务都用 root 运行，那一旦某个服务被黑客攻破，黑客就直接拿到了整个服务器的最高权限。反过来，如果 Nginx 用 nginx 用户运行，就算被攻破，黑客也只能拿到 nginx 用户的有限权限，无法进一步控制整个系统，危害就被限制住了。

讲完了用户，再来说说用户组。用户组的本质，其实就是**「权限的集合」**。

这就像公司里的部门划分：运维组管服务器、开发组管代码、财务组管工资，不同部门天然对应不同的权限，不用一个个给人授权，只要给部门授权就好了。Linux 的用户组也是一样的逻辑。

举个真实工作中的场景你就懂了：公司有10个开发，他们都需要访问项目目录 /data/project，如果你要给每个人单独授权这个目录，操作十次，非常麻烦。以后来了新开发，还要再加一次权限。

这时候用户组的优势就体现出来了：你只需要做三步：

1. 创建一个叫 dev 的用户组
2. 把所有10个开发的用户，都加入到 dev 组里
3. 给 /data/project 目录授权给 dev 组访问

以后再来新开发，只要把他加入 dev 组，自动就有了目录访问权限，不用再改一次目录权限，管理起来简单太多。

这就是用户组存在的核心意义：批量管理权限，降低管理成本。

讲完了概念，我们来看几个日常工作中最常用的操作，这些命令几乎每天都会用到。

查看类操作

• 查看当前登录的用户：

bash
whoami

输出直接就是当前用户名，非常简单。

• 查看当前用户属于哪些用户组：

bash
groups

比如输出 dev : dev docker，就说明当前用户 dev 属于 dev 主组和 docker 附加组。

• 查看用户的详细ID信息：

bash
id# 查看指定用户的信息id root

输出类似这样：

scss
uid=1000(dev) gid=1000(dev) groups=1000(dev), 998(docker)

uid 是用户ID，gid 是主组ID，groups 列出了所有所属的组。

创建类操作

• 创建一个新用户：

bash
useradd test

创建完成后需要设置密码才能登录：

bash
passwd test

输入两次密码就设置完成了。

• 创建一个新用户组：

bash
groupadd dev

• 将已有用户加入到用户组：

bash
usermod -aG dev test

这里一定要注意参数 -aG，a 是「追加」的意思，如果不加 -a，会把用户从原来的其他组里移除，只保留新加入的组，这个坑很多新手都踩过。

我们都知道 Linux 中「一切皆文件」，不管是普通的文本文件、二进制程序、还是目录、设备，在 Linux 里都被抽象成文件，每个文件都有自己的权限属性。

你可以用 ls -l 查看文件的权限，比如输出会有这么一串字符：

diff
-rwxr-xr--

很多新手第一次看到这个直接懵了，其实拆解开来非常简单。

权限只有三种核心类型

Linux 的权限本质上只有三种，对应三个字母：

这里很多人会搞混目录的权限，举个例子你就明白了：如果一个目录只有 r 权限，没有 x 权限，你能 ls 列出文件名，但没办法 cd 进去，也没办法访问目录里文件的内容——因为进入目录本身需要 x 权限。

权限分三类对象：你、你的组、其他人

Linux 给文件分配权限的时候，会把访问者分成三类，每类对象单独设置权限：

所以我们再看开头那串 rwxr-xr--，其实就是按顺序把三类对象的权限拼起来了，拆解开来就是：

所以这串字符串对应的数字权限就是 754，是不是一下就清晰了？

修改权限最常用的就是两个命令：chmod 改权限、chown 改所有者和所属组，我们一个个说。

chmod：修改文件权限

chmod 就是 change mode 的缩写，作用就是修改文件的权限，它有两种用法：数字写法和符号写法。

1、数字写法（最常用）

我们刚才说了，每个权限对应一个数值：r=4、w=2、x=1，把三个权限的数值加起来，就是这一类对象的权限数字。

所以最常见的几个权限组合你要记牢：

• 7
   = 4+2+1 = rwx：拥有读、写、执行全部权限
• 6
   = 4+2 = rw-：拥有读、写权限，没有执行
• 5
   = 4+1 = r-x：拥有读、执行权限，没有写
• 4
   = 4 = r--：只有读权限，什么都不能改

所以常见的命令比如：

bash
chmod 755 test.sh

对应的就是：所有者rwx（7）、组r-x（5）、其他人r-x（5），这也是可执行脚本最常用的权限。

再比如给普通文本文件设置权限：

bash
chmod 644 index.html

对应所有者rw-（6）、组r--（4）、其他人r--（4），任何人都不能执行，非常安全。

2、符号写法（适合改单个权限）

如果你只想给某一类对象加一个权限，不用改整体权限，就可以用符号写法，格式是 [u/g/o/a][+/-/=][r/w/x]。

比如给脚本加一个执行权限：

bash
chmod +x backup.sh

这里的 +x 就是给所有对象（a 省略默认就是所有）加执行权限，非常好记。

再比如：不让其他人修改这个文件：

bash
chmod o-w test.txt

就是给 o（其他人）减掉 w（写）权限，非常直观。

chown：修改文件的所有者和所属组

chown 是 change owner 的缩写，作用就是修改文件的所有者和所属组，格式非常简单：

bash
chown 用户名:组名 文件名

比如你部署网站的时候，网页文件需要让 Nginx 进程读取，所以可以改成：

bash
chown nginx:nginx /usr/share/nginx/html/index.html

就是把 index.html 的所有者改成 nginx，所属组也改成 nginx。

如果只想改所有者，不用改组，可以省略组名：

bash
chown nginx index.html

如果只想改组，可以在组名前面加冒号：

bash
chown :nginx index.html

如果要递归修改目录下所有文件的所有者，加个 -R 参数就可以了：

bash
chown -R nginx:nginx /usr/share/nginx/html/

这也是部署网站的时候非常常用的命令。

讲了这么多概念，我们来看几个工作中天天遇到的权限问题，你就能明白权限管理有多重要了。

场景1：网站打不开，报403 Forbidden

很多新手部署完 Nginx，访问网站直接出403，检查了一圈配置发现都没问题，最后其实就是权限错了：

Nginx 运行的时候用的是 nginx 用户，但是网页目录的所有者是 root，权限是 700，只有 root 能读，nginx 用户根本读不到网页文件，自然就返回403了。

解决方法也很简单，把目录和文件的所有者改成 nginx，或者给组加上读权限就好了。

场景2：执行脚本提示 Permission denied

你写了一个备份脚本 backup.sh，下载到服务器上执行：

bash
./backup.sh-bash: ./backup.sh: Permission denied

这个错误几乎所有人都遇到过，原因就是脚本没有加上执行权限，Linux 不允许你直接运行它。

解决方法也很简单，加个执行权限就好了：

bash
chmod +x backup.sh

再执行就没问题了。

场景3：程序启动失败，提示不能写日志

你的Java程序启动的时候报错，说 /var/log/app/ 目录下没法写日志，这也是典型的权限问题：程序运行的用户没有日志目录的写权限，自然写不进去，启动自然就失败了。

解决方法就是把日志目录的所有者改成程序运行的用户，给目录加上写权限就好了。

场景4：为什么禁止 chmod 777？

很多新人遇到权限问题，图省事直接敲 chmod 777，777 对应的权限是：所有者rwx、组rwx、其他人rwx，也就是说任何人都能读、能写、能执行这个文件，虽然能解决眼前的问题，但这在生产环境是极其危险的。

如果你的网站目录给了777权限，那黑客上传一个木马之后，直接就能执行它，拿到服务器权限，整个系统就沦陷了。就算不是网站，任何关键文件给了777，任何用户都能删除修改，很容易造成误操作事故。

所以行业里几乎所有公司都明确禁止生产环境使用 chmod 777，正确的思路永远是：谁需要权限，就给谁权限，最小权限原则，不要给所有人开放权限。

工作中遇到报错，第一时间就要想到「是不是权限出问题了」，给大家分享一套标准排错思路：

1. 先看你当前是什么用户：敲 whoami 确认你的身份，很多时候你用 tom 用户，却要修改 root  owned 的文件，自然报错。
2. 再看文件的权限和所有者是谁：敲 ls -l 文件名 看所有者、组、权限对不对。确认当前用户是不是所有者，有没有对应的权限。
3. 如果是目录，要检查上级目录的权限：很多时候文件本身权限对了，但上级目录不让进，照样访问不了，要从根目录一层层往下检查权限。
4. 如果是服务报错，看服务用什么用户运行：比如 Nginx、PHP 这些服务，都有自己的运行用户，不是你登录的用户能读就行，要服务的运行用户也能读才行。

按照这个思路走，绝大多数权限问题都能很快定位解决。

Linux 权限管理，本质上回答的就是一个核心问题：「谁，能对这个文件做什么」。

整个体系其实非常清晰：先给每个主体分配身份（用户），再把相同权限的用户归为一组（用户组），然后对每个文件，给所有者、组、其他人分别分配读、写、执行三种权限，最后通过 chmod 和 chown 调整权限和所有者，就完成了整个权限控制。

这套从设计之初就确立的多用户权限体系，也是 Linux 比很多系统更安全的核心原因——它把每个用户、每个服务的权限都限制在了合理的范围，不会一个服务出问题，整个系统都跟着完蛋。

很多时候，高手和新手的区别，不是会不会敲 chmod 命令，而是遇到一个奇怪的报错，能不能第一时间反应过来：哦，这大概率是权限问题。

最后留一个问题给大家：你工作中遇到过最奇葩的权限问题是什么？欢迎在留言区分享讨论。