前几篇文章里,我们从 Linux 和 Windows 的核心差异,一步步摸到了文件系统的目录树结构,又啃完了文件目录操作的基础与进阶命令,很多小伙伴跟着练完,终于能在终端里顺畅地查看、创建、修改文件了。
然而现实操作还是绕不开那句经典的报错:Permission denied。“我明明写好了脚本,怎么运行就提示权限不够?”“用普通用户改了下配置文件,怎么都保存不了,只能切 root?”“一遇到权限报错就直接 chmod 777,可总听人说这么做有风险,到底该怎么办?”
至今还记得,第一次在虚拟机里装完 CentOS,写了个简单的备份脚本,双击运行不了,在终端里执行就报权限不足。那时候不懂什么 rwx 权限,只在网上搜到一句 “chmod 777 文件名能解决所有权限问题”,就像捡到了万能钥匙,不管什么报错,先 777 再说。
直到后来跟着做运维,亲眼见到一台测试服务器因为网站目录被设了 777 权限,被恶意脚本上传了木马;也见过有人在生产环境乱改系统文件的所有者,导致核心服务直接起不来,凌晨两三点还在机房恢复数据。我才慢慢明白:Linux 的权限体系,从来不是为了给使用者设门槛,而是这个系统最核心的安全防线。而我们常说的权限管理三剑客chmod、chown、chgrp,就是守护这道防线的核心工具,也是每个学 Linux 的人,必须吃透的基本功。
Linux 的权限,到底在管什么?你遇到的80% 权限报错,根本不是命令不会用,而是没搞懂 Linux 权限的设计规则。
讲 Linux 和 Windows 的核心区别时提过,Windows 用的是 ACL 精细化访问控制列表,而 Linux 用的是经典的rwx三级权限模型,这也是整个 Linux 权限体系的根基。
Linux 里一切皆文件,不管是普通的文本、脚本,还是目录、硬件设备,都被系统当作文件来管理,而每个文件,都绑定了三套权限规则,分别对应三类用户:
所有者(user,简写 u):文件的创建者,默认拥有文件的最高控制权
所属组(group,简写 g):和所有者在同一个用户组的用户,组内用户可以共享预设的权限
其他用户(other,简写 o):既不是所有者,也不在所属组里的其他所有用户
而每一类用户,都对应三种基础权限,对文件和目录来说,这三种权限的作用天差地别,这也是最容易搞混的地方:
| | | |
| | | |
| | | |
| | 可以运行这个文件(比如 shell 脚本、二进制程序) | |
这里一定要划重点:目录的 x 权限,是你能操作这个目录里文件的前提。见过太多,给了文件 777 权限,却发现还是操作不了,一查才发现,文件所在的上级目录,连 x 权限都没给,自然连门都进不去,更别说改文件了。
还有一个核心原则,需刻在骨子里的:最小权限原则。能给 644 就不给 755,能给 755 就不给 777,只给用户完成操作必须的最小权限,多一分都不给。这不仅是为了系统安全,更是为了避免自己的误操作,给系统带来不可逆的损坏。
第一剑客:chmod - 权限配置的核心,不止是 755 和 644
chmod是change mode的缩写,顾名思义,就是用来修改文件/目录的读、写、执行权限,也是我们日常处理权限问题最常用的命令。很多人对它的认知,只停留在chmod 755 test.sh和chmod 644 test.conf,但其实它的用法远比这灵活,用对能解决绝大多数场景的权限需求,用错了也会埋下最大的安全隐患。
1. 数字法:好记又不易出错,优先掌握
这是我们最常用的方式,之前也简单提过,数字法的核心,就是用三个 0-7 的数字,分别对应所有者、所属组、其他用户的权限,每个数字都是 r=4、w=2、x=1 三个权限的和。
举几个最经典的例子,也是我们日常用得最多的权限配置:
755:所有者 rwx(4+2+1=7),所属组和其他用户 r-x(4+0+1=5)最常用在可执行脚本、程序文件、系统目录上。既保证了所有者能修改、执行文件,又限制了其他用户只能看和执行,不能修改,兼顾实用与安全。
644:所有者 rw-(4+2+0=6),所属组和其他用户 r--(4+0+0=4)配置文件的标准权限。配置文件不需要执行权限,只需要所有者能修改,其他人只能看,完全杜绝了非授权修改的可能,也避免了恶意脚本被执行的风险。
700:所有者 rwx(7),所属组和其他用户无任何权限(0)超级敏感的私人文件、root 用户的脚本,用这个权限最合适,除了所有者本人,其他人连看都看不了,绝对安全。
# 给单个文件设置权限
chmod 755 test.sh
# 给目录设置权限
chmod 755 /home/qw/project
# 递归修改目录及里面所有文件/子目录的权限(重点!加-R参数)
chmod -R 755 /home/qw/project
2. 符号法:精细化权限修改,不用记数字
很多人觉得符号法麻烦,其实在一些精细化修改的场景里,它比数字法更方便,不用因为改一个权限,就重新算一遍三个数字。
符号法的核心,是用u/g/o/a代表用户类别,用+/-/=代表权限操作,用r/w/x代表具体权限:
# 给脚本的所有者添加执行权限,其他权限不变
chmod u+x test.sh
# 给所有用户移除文件的写权限,防止被修改
chmod a-w test.conf
# 给所属组添加读和执行权限,其他用户移除所有权限
chmod g+rx,o-rwx test.sh
# 给目录里的所有.sh脚本,批量添加所有者执行权限
chmod u+x /home/qw/project/*.sh
这种只需要修改某一类用户的某一项权限的场景,用符号法比数字法方便太多,也不用怕算错数字,改坏了其他权限。
场景 1:给下载 / 编写的 shell 脚本,添加安全的执行权限
这是最常遇到的场景,Linux 里新建的文件,默认是没有执行权限的,哪怕你写的是脚本,也需要手动添加执行权限。很多人这里直接上chmod 777 test.sh,其实完全没必要,最安全规范的写法是:
# 只给所有者添加执行权限,其他用户保持只读,兼顾运行和安全
chmod 755 test.sh
# 或者用符号法,只加执行权限,不改动原有读写权限
chmod u+x test.sh
场景 2:给项目目录设置合理的权限,区分目录和文件
最容易踩的坑,就是用chmod -R 755 项目目录,把目录里所有的文件都加了执行权限。其实目录需要 x 权限才能进入,但普通的配置文件、文本文件,根本不需要执行权限,给了反而有安全风险。
正确的做法,是分开设置目录和文件的权限,一行命令就能搞定:
# 先给所有目录设置755权限(能进入、能查看)
find /home/qw/project -type d -exec chmod 755 {} \;
# 再给所有普通文件设置644权限(能读、所有者能改,无执行权限)
find /home/qw/project -type f -exec chmod 644 {} \;
这是我接触到管理项目目录的标准操作,既保证了目录能正常访问,又杜绝了普通文件被赋予执行权限的安全隐患。
场景 3:给敏感配置文件加锁,禁止所有用户修改
比如 ssh 的配置文件、系统的用户配置文件,我们只希望root能修改,其他人哪怕是同组用户,也只能看不能改,就可以用 644 权限,甚至更严格的 600 权限:
# 系统配置文件,仅root可修改,其他人只读
chmod 644 /etc/ssh/sshd_config
# 私人密钥文件,必须600权限,多一点权限ssh都会拒绝使用chmod 600 /root/.ssh/id_rsa
这里提一句,ssh 的私钥文件,如果权限给得太宽松,比如其他用户能读,ssh 会直接拒绝使用这个密钥,就是为了防止私钥泄露,这也能看出来 Linux 对权限的严格要求。
如果一遇到权限报错,根本不想着排查原因,直接 777 一键解决,意味着系统里的任何一个用户,都能修改、删除、执行这个文件,相当于你家的门不仅没锁,还在门口贴了张纸条 “屋里没人,随便进”。所以要养成一个习惯:修改权限前,先想清楚 “这个文件谁需要用?需要用它做什么?”,只给完成这件事必须的权限,多一分都不给。
为什么新建的文件,默认权限是 644,新建的目录默认是 755?这其实是umask(权限掩码)决定的。简单来说,umask 就是用来 “拿掉” 一些默认权限,保证新建的文件 /目录不会一创建就权限过大。Linux 系统默认的 umask 值是 022,对应的规则是:
可以直接在终端输入umask,查看当前系统的掩码值。如果是私人用的测试环境,想让新建的文件只有自己能操作,可以把 umask 设为 077,这样新建的文件默认就是 600,目录是 700,安全性更高。
# 查看当前umask值
umask
# 临时修改umask为077(重启终端后失效)
umask 077
文件权限组知识及chown命令:很多时候,你遇到的权限报错,根本不是权限数字给得不够,而是文件的所有者 / 所属组不对。