Linux文件与目录rwx权限详解：从Permission denied到安全配置-北京尧图网络

在实际运维和开发中Permission denied大概是出现频率最高的报错之一。很多人第一次遇到它时第一反应是chmod 777把所有权限开到最大问题确实消失了但为什么消失、这样做有什么后果往往说不清楚。更麻烦的是另一类情况同样是rwx加在文件上能执行加在目录上却完全不是那个意思于是出现了我有写权限为什么删不掉文件目录只读为什么还能 cd 进去这类反复困扰新手的问题。这篇文章就围绕一个核心问题展开rwx这三种权限作用在普通文件和目录上分别代表什么。文章面向刚接触 Linux 的开发者、需要自己部署服务的后端同学以及正在准备运维相关面试的读者。读完之后你应该能做到三件事看懂ls -l输出的每一个字符、在出问题时快速判断是哪个权限位缺失、以及在上线前给出一个安全且够用的权限方案。全文会先讲清权限模型的基本构成再分别拆解文件和目录两个场景然后用一套可以完整复现的实验把结论验证一遍最后给出特殊权限位、排错清单和工程实践建议。所有命令都可以直接复制到测试机上执行建议边看边敲。1. 背景与核心概念1.1 一句话说清 Linux 的权限模型Linux 是一个多用户操作系统同一台机器上可能同时有多个用户、多个进程在跑彼此的资源和数据必须隔离。权限机制就是这套隔离规则的实现方式它规定了谁能对什么做哪些操作。这三个要素对应三个维度。谁指的是身份Linux 把访问者分成三类文件属主owner用u表示、属组group用g表示、其他人others用o表示全部身份用a表示。什么指的是被访问的对象主要就是文件和目录另外还有设备文件、套接字等特殊类型。哪些操作就是读r、写w、执行x这三种基本权限。理解了这三个维度权限问题就变成了一个填空题某个身份对某个对象缺少了某个权限位。绝大多数Permission denied都可以用这个模板定位而不是靠试。1.2 为什么同样的 rwx 会有两种含义这是本文最关键的一个认知点。r、w、x这三个字母的含义取决于它们作用在什么类型的对象上。作用在普通文件上时它们描述的是对文件内容的操作能力能不能读出来、能不能改掉、能不能当作程序运行。这里的对象是字节流。作用在目录上时它们描述的是对目录条目也就是里面的文件名列表的操作能力能不能看到里面有哪些文件、能不能进到这个目录里、能不能在里面创建或删除条目。这里的对象是一张名字到 inode 的映射表。这两套语义完全不同所以在目录上有写权限并不等于能修改目录里的文件内容它意味着能在目录里增删文件名。这个区别是大量误解的根源后面会用完整的实验来验证。1.3 三种身份与权限位的组织方式每个文件在磁盘上都有一个 inodeinode 里记录着属主 UID、属组 GID以及一组 12 位左右的权限标志。日常看到的是其中 9 位分成三组每组三位依次是rwx-rwxr-xr-- 1 tom devs 1024 Mar 10 10:00 deploy.sh |└┬┘└┬┘└┬┘ | │ │ └── others: r-- | │ └───── group : r-x | └──────── owner : rwx └────────── 文件类型- 普通文件d 目录l 链接第一位是文件类型标识常见的有-普通文件、d目录、l符号链接、c字符设备、b块设备、s套接字、p命名管道。后面九位就是本文要重点讨论的内容。判断顺序是如果访问者的 UID 等于文件属主就用第一组否则如果访问者所属的某个组等于文件属组就用第二组都不匹配才用第三组。这个短路特性很重要——一个用户即使属于属组只要他是属主就只按属主那组权限判定不会取两组的并集。1.4 掌握它能解决哪些真实问题权限知识不是考试内容它直接对应日常工作的几个高频场景部署 Java 或 Python 服务时启动脚本没有执行权限导致Permission deniedNginx 或 Tomcat 的静态资源目录权限配错导致 403团队共享目录里A 用户的文件 B 用户删不掉定时任务脚本被chmod -R误伤后整站挂掉以及安全审计时被要求把777目录收窄。这些问题的解法都建立在对rwx语义的准确理解上。下面我们先把实验环境准备好。2. 环境准备与命令速查2.1 实验环境说明本文所有命令都是 POSIX 标准工具ls、chmod、chown、umask、stat、getfacl在主流 Linux 发行版上行为一致包括 CentOS、Rocky Linux、Ubuntu、Debian、openEuler 等。不同发行版在默认umask、默认用户组策略上可能有差异本文会指出这些差异点具体数值请以你的实际环境为准。需要特别注意的一点是验证权限效果必须用普通用户不能用 root。root 拥有CAP_DAC_OVERRIDE能力会绕过绝大多数读、写权限检查你用 root 去测目录没有写权限能不能删文件结论一定是错的。这是很多人做实验失败的根本原因。建议在一台测试机或虚拟机上进行不要在生产环境操作。下面创建实验用的普通用户和目录。# 以 root 执行创建测试用户如果已存在可跳过 useradd -m tester echo tester:Test12345 | chpasswd # 创建实验目录并交给测试用户 mkdir -p /tmp/permtest chown tester:tester /tmp/permtest chmod 755 /tmp/permtest # 切换到测试用户进行后续实验 su - tester如果提示useradd: command not found说明系统使用的是精简镜像需要先安装shadow-utilsRHEL 系或passwd包Debian 系。这一步只是为了让实验环境干净实际排查线上问题时直接用出问题的账号复现即可。2.2 查看权限的几条核心命令排查权限问题的第一步永远是看清楚现状。ls -l是最常用的但它只显示基础信息遇到 ACL 或特殊权限位时容易漏看所以建议同时掌握stat和getfacl。ls -l /tmp/permtest # 查看目录下条目的权限 ls -ld /tmp/permtest # 查看目录本身的权限注意 -d stat /tmp/permtest # 查看八进制权限、inode、时间戳等完整信息 namei -l /tmp/permtest/sub/file # 逐级显示路径上每一层目录的权限排查神器 getfacl /tmp/permtest # 查看 ACL 扩展权限有 ACL 时 ls -l 会显示 id tester # 查看用户 UID 和所属的组其中namei -l值得重点推荐。当路径层级很深时cd失败或访问文件失败往往不是最后那个文件的问题而是路径中间某一层目录缺了x。namei -l会把路径上每一级的权限列出来一眼就能看出是哪层断的。stat的输出里有一个Access: (0755/drwxr-xr-x)字段八进制和符号两种形式同时给出对照起来非常直观排查时比ls -l更省事。2.3 本文实验的约定为了避免混乱后面所有实验都遵循同一套约定实验目录固定为/tmp/permtest属主固定为tester所有验证操作都以tester身份执行。需要验证其他人权限时再额外创建一个用户other用su - other切换。# 以 root 执行创建第二个测试用户 useradd -m other echo other:Test12345 | chpasswd这样一来tester就是属主other就是其他人两种身份的权限判定结果可以分别观察实验结论更可靠。3. rwx 对普通文件的作用3.1 r读取文件内容rread作用在文件上表示可以读取文件的字节内容。对应的系统调用是open()时带O_RDONLY或者read()。日常表现是cat、less、head、grep能正常输出内容cp能把它复制走程序能把整个文件读进内存。一个容易被忽略的点是r只控制内容不控制元数据。即使没有任何权限只要路径上的目录有x你依然可以用ls -l看到文件大小、属主、修改时间可以用stat看到 inode 号。因为这些信息来自目录和 inode不来自文件内容。所以文件权限 000 但别人还是能看到文件名和大小不是权限失效而是设计如此。# 实验去掉读权限 cd /tmp/permtest echo hello linux permission file1.txt chmod 000 file1.txt cat file1.txt # 以非 root 用户执行会报 Permission denied ls -l file1.txt # 依然能看到名字、大小、权限、时间 stat file1.txt # 依然能看到 inode、权限、时间戳如果此时你用 root 执行cat file1.txt内容照样能输出。这就是前面强调的 root 绕过机制不要用它来判断权限配置是否正确。3.2 w修改文件内容wwrite作用在文件上表示可以修改文件内容。注意措辞是内容不是文件本身。有w权限时你可以用echo 追加、用sed -i替换、用truncate截断也可以用重定向覆盖。对应的系统调用是open()带O_WRONLY或O_RDWR。这里有一个细节覆盖文件内容需要w但清空文件内容 file也只需要w不需要r。所以给了一个用户-w-权限他可以把文件清空却读不出里面原来是什么。这个特性在日志文件场景里偶尔会被用到让应用只能追加写、不能读保护敏感日志内容。另一个高频误解是有w就能删除文件。这是错的。文件本身的w位和删除这个文件没有任何关系删除动作由父目录的权限决定这一点会在第 4 节详细展开也是本文最重要的一个结论。# 实验只给写权限不给读权限 chmod 200 file1.txt echo append line file1.txt # 成功可以追加 cat file1.txt # 失败Permission denied rm file1.txt # 是否成功取决于父目录权限而不是这里的 2003.3 x执行文件xexecute作用在文件上表示这个文件可以被当作程序加载执行。对于二进制可执行文件内核会把文件映射进内存并跳转到入口点对于脚本文件需要由解释器/bin/bash、/usr/bin/python3读取后执行。这里有个重要区别二进制程序的执行只需要x而脚本的执行需要r和x。因为脚本本身不是机器码内核识别到 shebang#!/bin/bash后会把文件交给解释器解释器再以普通文件读取的方式打开脚本此时就需要读权限。所以脚本权限配成--x会报错必须至少是r-x。还有一种情况即使脚本没有x用bash script.sh或sh script.sh依然能跑因为这时是解释器在主动读文件只用到r权限。只有./script.sh这种直接执行的方式才需要x。理解这一点就能解释为什么我在命令行里能跑写进 crontab 就报 Permission denied之类的怪问题。# 实验脚本的执行权限 cat hello.sh EOF #!/bin/bash echo hello from script EOF chmod 644 hello.sh ./hello.sh # 报 Permission denied bash hello.sh # 正常输出因为只需要读权限 chmod 100 hello.sh # 只有执行权限 ./hello.sh # 依然报错因为解释器读不到脚本内容 chmod 755 hello.sh ./hello.sh # 正常输出3.4 三个权限位的组合速查把上面的结论整理成表方便对照。这里的父目录指文件所在的目录其他指不在属主和属组内的用户。权限含义典型命令常见误区r读取文件内容cat、less、cp以为没有r就看不到文件名w修改文件内容echo 、sed -i以为有w就能删除文件x作为程序执行./app、./run.sh以为脚本只要x就够rw-可读可写不可执行配置文件、日志配置文件不需要x给了反而危险r--只读证书、公钥忘记属主也要只读避免误改r-x可读可执行二进制程序、脚本脚本必须带r不能只有xrwx全权限一般不给普通文件对文件给x会扩大攻击面一个实用的记忆方法是对文件而言r和w管内容x管能不能当程序跑。删除、重命名、移动这些操作通通不看文件自身的权限只看它所在目录的权限。4. rwx 对目录的作用核心4.1 r能否列出目录内的文件名目录的r权限控制的是能不能读取目录条目列表。有r时ls能把目录里的文件名全部列出来没有r时ls会直接报Permission denied。但这里有一个非常微妙的点只有r没有x时ls能列出名字但ls -l会失败。原因在于详情大小、权限、时间戳需要读取每个条目的 inode而读取 inode 需要x权限穿过目录。所以你会看到一个奇怪的输出文件名列出来了但属性全是?????????。这个现象是判断目录缺 x的典型特征。# 实验只有 r 没有 x 的目录 cd /tmp/permtest mkdir -p dir_r_only echo content dir_r_only/a.txt chmod 400 dir_r_only # r-------- 属主有 r无 w 无 x ls dir_r_only # 能列出 a.txt ls -l dir_r_only # 能列出名字但属性显示 ?????????并伴随报错 cd dir_r_only # Permission denied cat dir_r_only/a.txt # Permission denied因为无法穿越目录这里就能看出r和x的分工r是看名单x是走进门。只看名单不进门你只知道有哪些文件但拿不到任何细节也碰不到内容。4.2 x能否进入目录、穿越目录目录的x权限execute也叫 search 权限是整个权限体系里最容易被低估的一位。它决定两件事能不能cd进入这个目录能不能穿过这个目录去访问里面的文件或子目录。穿越这个概念很关键。访问/a/b/c.txt时内核会逐级解析路径每经过一层目录都需要该目录的x权限。只要路径上任意一层目录缺x即使最终文件的权限是777访问也会失败。这就是为什么有时候ls -l看单个文件权限完全正常cat却报Permission denied——问题出在中间某一层目录上。反过来只有x没有r的目录也很有意思你cd进去没有问题只要知道确切文件名就能cat、vim、cp但ls会失败因为你无法列出名单。这种行为在某些场景下是特意设计的比如一个共享目录允许别人按约定路径访问自己的文件但不允许浏览别人的文件。# 实验只有 x 没有 r 的目录 mkdir -p /tmp/permtest/dir_x_only echo secret /tmp/permtest/dir_x_only/known.txt chmod 111 /tmp/permtest/dir_x_only # ---x--x--x cd /tmp/permtest/dir_x_only # 成功进入 ls # Permission denied cat known.txt # 成功因为知道文件名 cat unknown.txt # 报错文件名不存在而非权限问题 cd .. # 可以正常退出用namei -l可以非常直观地验证路径上每一层都要有 x这个结论。随便找一个深层路径执行输出会逐行列出每一级的权限缺x的那一行会直接暴露问题。4.3 w能否在目录内创建、删除、重命名目录的w权限控制的是目录条目的增删改。有w时你可以在这个目录里touch新文件、mkdir子目录、rm删除文件、mv重命名或移动文件。没有w时这些操作全部报Permission denied即使你对里面的文件本身有完全权限。这是全文最重要的一条结论再强调一遍删除一个文件需要的是文件所在目录的w和x与文件自身的权限无关。所以会出现两种看起来矛盾的现象文件权限000也能被删掉只要所在目录可写文件权限777也可能删不掉因为所在目录不可写。另外要注意w单独存在时几乎没用。因为在目录里创建或删除条目时内核需要先解析路径、定位 inode这需要x。只给w不给x的目录你既进不去也列不出实际什么都做不了。所以目录的有效写权限指的是wx组合。# 实验目录没有 w 时文件权限再大也删不掉 mkdir -p /tmp/permtest/dir_ro echo data /tmp/permtest/dir_ro/locked.txt chmod 777 /tmp/permtest/dir_ro/locked.txt # 文件全权限 chmod 555 /tmp/permtest/dir_ro # 目录只读 rm /tmp/permtest/dir_ro/locked.txt # Permission denied echo new /tmp/permtest/dir_ro/new.txt # Permission denied无法创建反过来验证也很有说服力把目录改成755属主可写文件改成000属主依然能删掉它。原因很简单删除操作修改的是目录的内容文件本身一个字节都没动。4.4 目录权限组合矩阵把r、w、x在目录上的所有组合列出来配合实际表现这张表建议直接背下来。权限数字能否cd能否ls能否ls -l能否访问已知文件能否增删文件---0否否否否否--x1能否否能否-w-2否否否否否-wx3能否否能能r--4否能否否否r-x5能能能能否rw-6否能否否否rwx7能能能能能从表里能读出几条规律。第一x是能不能进门的开关没有x一切访问都免谈包括r和w的效果都会大打折扣。第二r-x是绝大多数目录的标准配置既能进能看又不能随便改。第三-wx这种组合虽然能增删但列不出内容实际使用极少属于特殊场景。日常最常用的目录权限就是755属主全权限其他人只读可进和775同组可写、700仅属主可见。这三种能覆盖绝大部分需求。5. 权限的表示与修改5.1 十位权限串的完整读法ls -l输出的第一位是文件类型后九位是权限。九位中如果出现s或t说明开启了特殊权限位这时的x位被替换显示属主位的s表示 SUID属组位的s表示 SGID其他人位的t表示 Sticky。如果显示的是大写S或T说明特殊位开了但对应的x没开这种配置通常是错误的会导致程序无法执行。-rwsr-xr-x 属主位 sSUID 已开启且 x 位有效可执行 -rwSr-xr-x 属主位 SSUID 已开启但 x 位无效不可执行SUID 实际不生效 drwxrwxrwt 其他人位 tSticky 已开启且 x 位有效/tmp 的典型配置看到S或T大写时基本可以判定是chmod时算错数字导致的比如把chmod 4755误写成chmod 4644。5.2 数字法最常用的修改方式数字法把三位权限当成三个二进制位r4、w2、x1相加得到一个 0 到 7 的数字。三组身份依次拼起来就是三位八进制数。chmod 755 dir # rwxr-xr-x chmod 644 file.conf # rw-r--r-- chmod 600 id_rsa # rw-------私钥的标准权限 chmod 700 ~/.ssh # drwx------ chmod 775 shared_dir # rwxrwxr-x同组可写 chmod 1777 /tmp/download # 带 Sticky 的完全共享目录数字法的优点是简洁缺点是可读性差。建议在脚本里使用时加上注释写清每一位对应的身份避免几个月后自己都看不懂。5.3 符号法更精确的表达符号法用u/g/o/a指定身份用/-/指定动作用r/w/x指定权限。它的好处是可以只改某一位而不影响其他位。chmod ux deploy.sh # 只给属主加执行权限 chmod go-w file.conf # 去掉属组和其他人的写权限 chmod ar public.txt # 所有人可读 chmod grx dir # 把属组权限精确设置为 r-x其他位不动 chmod -R gr /var/www/html # 递归给属组加读权限注意递归风险 chmod us /usr/local/bin/tool # 加 SUID chmod gs /data/share # 加 SGID常用于共享目录 chmod ot /data/upload # 加 Sticky符号法里有一个特殊权限X大写含义是仅当对象是目录或者文件本身已经带有执行位时才加x。这个写法专门用来解决递归加执行权限的问题chmod -R aX dir会给所有目录加x但不会给普通文件加x。这个坑很常见。用chmod -R 755 dir递归一个网站目录所有.jpg、.css、.html都被加上了执行位虽然不影响功能但扩大了攻击面也不符合安全基线要求。正确做法是分开设置# 目录 755文件 644这是 Web 目录的标准做法 find /var/www/html -type d -exec chmod 755 {} \; find /var/www/html -type f -exec chmod 644 {} \;5.4 chown、chgrp 与 umaskchmod管权限chown管归属两者配合才能完成一次完整的权限配置。最常见的组合是改归属设权限。chown tom file.txt # 只改属主 chown tom:devs file.txt # 同时改属主和属组 chown -R tom:devs /data/app # 递归改归属 chgrp devs file.txt # 只改属组umask决定的是新建文件和目录的默认权限。它的作用是从最大权限里减掉。普通文件最大是666默认不给执行位目录最大是777。所以umask 022下新建文件是644新建目录是755。umask # 查看当前值常见为 0022 umask 027 # 临时修改文件 640目录 750 umask -S # 以符号形式显示umask是进程级设置退出 shell 就失效。要永久生效需要写入/etc/profile、/etc/bashrc或用户的~/.bashrc。生产服务器上比较推荐的取值是027它让同组用户可读、其他人完全无权限比022更严格。6. 完整实战一步步验证 rwx 的真实行为这一节把前面的结论串成一个完整的实验流程。建议在测试机上照做一遍亲手看到结果比读十遍结论都管用。6.1 搭建实验环境先准备目录和文件把属主设成tester然后用tester身份操作。su - root mkdir -p /tmp/lab chown tester:tester /tmp/lab su - tester cd /tmp/lab mkdir -p docs scripts uploads echo readme content docs/readme.txt printf #!/bin/bash\necho ok\n scripts/run.sh chmod 644 docs/readme.txt chmod 644 scripts/run.sh ls -lR /tmp/lab预期看到docs、scripts、uploads三个目录权限都是drwxr-xr-xdocs/readme.txt是-rw-r--r--。6.2 验证文件的 rwx 效果逐项去掉权限观察对应操作的变化。# 1) 去掉读权限 chmod 200 docs/readme.txt cat docs/readme.txt # Permission denied ls -l docs/readme.txt # 依然可见 echo append docs/readme.txt # 成功说明 w 独立生效这一步验证了两个结论w和r互相独立ls -l的信息不依赖文件自身的读权限。# 2) 去掉执行权限 chmod 644 scripts/run.sh ./scripts/run.sh # Permission denied bash scripts/run.sh # 输出 ok说明只需要读权限 chmod 100 scripts/run.sh # 只有执行权限 ./scripts/run.sh # 依然失败解释器读不到脚本 chmod 755 scripts/run.sh ./scripts/run.sh # 输出 ok这一步验证了脚本必须同时具备r和x而二进制程序只需要x。6.3 验证目录的 rwx 效果这是实验的核心部分。对同一个目录逐次修改权限记录每次的表现。# 情况一只有 r chmod 400 docs ls docs # 能列出 readme.txt ls -l docs # 属性显示 ?????????并报错 cd docs # Permission denied cat docs/readme.txt # Permission denied# 情况二只有 x chmod 111 docs cd docs # 成功 ls # Permission denied cat readme.txt # 成功已知文件名即可 cd ..# 情况三只有 w chmod 200 docs cd docs # Permission denied ls docs # Permission denied touch docs/new.txt # Permission denied# 情况四r-x标准目录权限 chmod 555 docs cd docs ls -l cd .. touch docs/new.txt # Permission denied因为没有 w从这四组结果里可以非常清晰地看到x是所有访问的前提r管列表w管增删。三者缺一对应的能力就消失。6.4 验证删除文件看目录这个关键结论这是最值得亲手做一遍的实验做完之后对权限的理解会上一个台阶。# 目录不可写文件 777依然删不掉 mkdir -p /tmp/lab/ro_dir echo x /tmp/lab/ro_dir/f.txt chmod 777 /tmp/lab/ro_dir/f.txt chmod 555 /tmp/lab/ro_dir rm /tmp/lab/ro_dir/f.txt # Permission denied # 目录可写文件 000照样删得掉 mkdir -p /tmp/lab/rw_dir echo y /tmp/lab/rw_dir/g.txt chmod 000 /tmp/lab/rw_dir/g.txt chmod 755 /tmp/lab/rw_dir rm /tmp/lab/rw_dir/g.txt # 删除成功再补一个反向验证把ro_dir的权限加回去文件虽然只有777本来就是 777删除立刻成功。整个过程里文件本身的权限一次没变变的只是父目录。chmod 755 /tmp/lab/ro_dir rm /tmp/lab/ro_dir/f.txt # 成功6.5 实验结论汇总把上面所有观察整理成一张对照表作为最后的结论沉淀。操作对象操作需要的权限位说明文件读取内容文件的r与目录无关前提是路径有x文件修改内容文件的w清空文件也只需要w文件执行二进制文件的x脚本额外需要r文件删除父目录的wx与文件自身权限无关文件重命名父目录的wx同上目录ls列名目录的r只给r时无法看详情目录cd进入目录的x路径上每一级都需要目录访问已知文件目录的x不需要r目录新建/删除/改名目录的wx只给w无效路径任意访问路径上所有目录的x用namei -l排查7. 特殊权限位与常见误区7.1 SUID以属主身份执行SUIDSet User ID设置在可执行文件上效果是任何用户执行它时进程的有效 UID 会临时变成文件属主。最经典的例子是/usr/bin/passwd普通用户需要修改自己的密码而密码存在/etc/shadow里这个文件只有 root 可写靠的就是passwd的 SUID 位。ls -l /usr/bin/passwd # -rwsr-xr-x. 1 root root ... /usr/bin/passwd配置方式是chmod us file或chmod 4755 file。需要特别提醒SUID 是提权风险的集中地任何带 SUID 位的自定义程序都必须经过严格审计确认程序内部没有可以被利用来执行任意命令的逻辑。上线前的安全基线检查里通常会要求列出全部 SUID 文件并逐个确认来源。# 排查系统里所有 SUID 文件只读操作安全 find / -perm -4000 -type f 2/dev/nullSUID 作用在目录上没有意义Linux 上会忽略不要给目录设置 SUID 指望新建文件继承属主那是 SGID 的活。7.2 SGID目录里的文件继承属组SGID 作用在目录上时非常实用在这个目录里新建的文件和子目录属组会自动继承目录的属组而不是创建者的主组。这个特性解决了团队协作里的一个老问题——A 建的文件默认属组是 A 的主组B 即使在同一目录下也改不了除非每个人都把自己加进对方的组。# 共享目录的标准配置 mkdir -p /data/share chown :devs /data/share chmod 2775 /data/share # 或者 chmod gs /data/share ls -ld /data/share # drwxrwsr-x. 3 root devs ... /data/share注意输出里的s它出现在属组位上。此时任何属于devs组的用户在/data/share里新建文件属组都是devs配合umask 002就能实现组内自由协作。SGID 作用在文件上时效果是执行时以文件属组身份运行用法比 SUID 少得多了解即可。7.3 Sticky限制删除Sticky 位作用在目录上效果是即使目录对所有用户可写也只有文件属主、目录属主或 root能删除或重命名目录里的文件。这是共享目录防误删的标准手段。/tmp就是最典型的例子权限是drwxrwxrwt所有人都能往里写但删不掉别人的文件。ls -ld /tmp # drwxrwxrwt. 20 root root ... /tmp # 自己搭一个受保护的共享上传目录 mkdir -p /data/upload chmod 1777 /data/upload ls -ld /data/upload # drwxrwxrwt. 2 root root ... /data/upload最后一位的t就是 Sticky 标志。如果没有它一个 1777 目录就退化成普通的 777任何人都能删掉别人的文件这是很典型的安全隐患。给上传目录配权限时1777几乎是最低要求。7.4 chmod -R 的连锁伤害chmod -R 755是最常见的误操作之一。它会无差别地给目录里所有文件加上执行位包括图片、文本、配置文件。这不仅让权限失去意义还可能让某些安全检查直接判为不合规。更危险的是chmod -R 777。它把整个目录树开放给所有用户任何本地账号都能改写代码或配置一旦有低权限账号被攻破攻击者就能直接篡改 Web 目录下的脚本。生产环境里这类操作必须在上线前被明令禁止。正确的递归写法是按类型区分处理# 目录 755文件 644安全且规范 find /var/www/html -type d -exec chmod 755 {} \; find /var/www/html -type f -exec chmod 644 {} \; # 需要可执行权限的脚本单独处理 find /var/www/html/bin -type f -name *.sh -exec chmod 755 {} \;如果一定要用chmod -R用大写的X代替小写xchmod -R aX dir只给目录和已有执行位的文件加x能避免大部分误伤。8. 常见问题与排查思路8.1 高频报错对照表问题现象常见原因排查与解决cat: xxx: Permission denied文件缺r或路径某层目录缺x用namei -l逐级检查先确认路径通不通bash: ./run.sh: Permission denied脚本缺x或缺少 shebangchmod x run.sh确认首行是#!/bin/bash./run.sh: /bin/bash^M: bad interpreter文件是 Windows 换行dos2unix run.sh或sed -i s/\r$// run.shls: cannot open directory: Permission denied目录缺rchmod r dir注意同时保留xcd: Permission denied目录缺xchmod x dir别只想着加rrm: cannot remove: Permission denied父目录缺w或x检查父目录权限不是文件本身touch: cannot touch: Permission denied目录缺wchmod w dir注意同步xls -l显示?????????目录有r无x给目录补x属主也无法修改文件文件被chattr i锁定lsattr查看chattr -i解锁明明改了权限却没生效路径上有挂载点或 ACL 覆盖getfacl检查 ACLfindmnt检查挂载选项8.2 一套可复用的排查顺序遇到权限问题建议固定按下面的顺序走不要跳步。第一步确认当前身份。执行id看 UID 和所属组很多时候问题出在你以为自己是属主其实不是。第二步确认目标文件的实际权限和归属。用stat而不是ls -l因为stat会同时给出八进制权限和 ACL 的存在情况。第三步检查整条路径。用namei -l /path/to/file逐级看每一层目录是否有x。这一步能解决大部分文件权限看着没问题但就是访问不了的情况。第四步确认有没有额外限制。检查 SELinux 状态getenforce、文件系统挂载选项findmnt是否ro挂载、文件不可变属性lsattr。第五步确认进程身份。如果问题出现在服务里而不是命令行要确认服务是以哪个用户跑的ps -ef | grep 服务名看第一列。很多命令行能跑、服务跑不了的问题本质是两个不同用户在访问同一个文件。8.3 root 为什么看起来不受限制root 拥有绕过读、写、权限检查的能力所以chmod 000的文件 root 照样能读能写。但有两个例外值得记住一是执行文件时root 也需要至少一个x位任意一组否则会得到Permission denied二是当文件系统以只读方式挂载时root 也写不进去。这个特性给排查带来一个陷阱用 root 测权限结论永远是没问题。所以复现权限问题时一定要切到真正出问题的普通用户身份下操作。9. 最佳实践与工程建议9.1 按最小权限原则分配权限配置的第一原则是够用即可。给多了不是方便是风险。具体到实践中Web 静态资源目录用755/644上传目录用1777或者775加 SGID配置文件用640属组设成服务运行用户所在的组私钥文件强制600.ssh目录强制700日志目录至少750避免其他用户读取业务数据。777应该被视为一个需要解释的例外而不是默认选项。如果某个目录必须777优先考虑改成1777加 Sticky或者用 SGID 配合2775把风险收窄。9.2 用组来管理协作而不是靠放开权限多人协作目录的推荐做法是建一个业务组把相关用户加进去目录设成2775配合umask 002。这样组内成员可以自由读写组外用户完全无权限同时新文件自动继承属组不会出现新建文件别人改不了的问题。# 团队共享目录的标准落地流程 groupadd devs usermod -aG devs alice usermod -aG devs bob mkdir -p /data/project chown -R root:devs /data/project chmod 2775 /data/project # 让组内新建文件默认 664、目录 775 echo umask 002 /etc/profile.d/devs_umask.sh这套配置比直接chmod 777安全得多也比每个人单独授权好维护。新增成员只需usermod -aG不用改任何文件权限。9.3 变更前的备份与验证任何涉及chmod -R、chown -R的操作都建议先在测试目录验证一遍确认find的匹配条件没问题再对生产目录执行。生产环境操作前至少记录一份当前权限快照出问题时可以对照恢复。# 导出权限快照便于回滚比对 find /var/www -printf %m %u %g %p\n /root/perm_backup_$(date %F).txt # 恢复时按快照逐条比对不要凭记忆改同时要明确一点任何对生产环境的权限变更都需要走变更流程、有授权、有回滚方案。权限调整看起来只是改几个数字实际影响面可能覆盖整个服务慎之又慎。9.4 定期做权限审计服务器跑久了权限会逐渐失控临时排查时加的777忘了收测试脚本留下的 SUID 没人清离职同事的账号还在组里。建议把权限审计做成定期任务。# 找出全局可写的目录排除 /tmp、/proc 等系统目录 find / -xdev -type d -perm -0002 ! -perm -1000 2/dev/null # 找出全局可写的文件 find / -xdev -type f -perm -0002 2/dev/null # 列出所有 SUID/SGID 文件 find / -xdev $ -perm -4000 -o -perm -2000 $ -type f 2/dev/null第一条命令特意排除了带 Sticky 的目录! -perm -1000因为1777是合理的它筛出来的是真正的任何人可写且无保护的目录这些才是需要处理的对象。9.5 记录与文档化权限配置最好能落到文档或配置管理工具里而不是只存在于某台机器上。至少要做到每个自定义目录的权限和归属有明确说明为什么是这个值写清楚服务启动用户的归属关系写清楚特殊权限SUID/SGID/Sticky的使用有记录和审批。否则下一次有人接手看到一堆不明所以的777和2775要么不敢动要么一刀切改掉导致故障。文档的成本远低于事故成本。10. 复盘与下一步把全文的核心结论压缩成几句话方便回顾。r、w、x在文件和目录上是两套完全不同的语义。文件上r读内容、w改内容、x能执行三者互不干扰脚本需要rx而二进制只需要x。目录上r决定能不能看名单x决定能不能进门和穿越w决定能不能增删条目而且w必须配合x才有意义。最重要的一条删除和重命名文件看的是父目录的wx不是文件本身的权限。这一条能解释绝大多数我明明有权限为什么删不掉的困惑。判断任何权限问题的通用思路是定位身份 → 看目标权限 → 检查整条路径 → 排除 ACL/SELinux/挂载限制用namei -l和stat这两个工具基本能覆盖八成场景。下一步可以继续深入的方向有几个。一是 ACLsetfacl/getfacl能实现比三组身份更细粒度的授权适合一个目录要同时给多个不同组不同权限的场景。二是 SELinux 和 AppArmor它们是在传统rwx之外的另一层强制访问控制很多权限都对但还是被拒绝的问题最终都指向这里。三是sudo的精细化配置理解如何在不给 root 密码的前提下授权特定命令。四是容器场景下的 UID 映射Docker 挂载卷时的权限问题本质还是这套模型只是多了一层命名空间。建议至少把第 6 节的实验完整做一遍尤其是删除文件看目录那组。亲手验证过的结论比读来的扎实得多。上线前权限检查清单[ ] 确认没有业务目录是777共享目录用1777或2775[ ] 确认脚本都有x且首行 shebang 正确换行符是 LF[ ] 确认私钥600、.ssh目录700、配置文件640[ ] 确认 Web 目录是目录 755 / 文件 644没有递归加x[ ] 确认服务运行用户对所需目录有最小够用的权限[ ] 确认 SUID 文件清单已审计无来源不明的条目[ ] 确认已导出一份权限快照出问题可对照回滚[ ] 确认变更经过测试环境验证并有授权记录

Linux文件与目录rwx权限详解：从Permission denied到安全配置

相关推荐

十万条数据导出实战：避免内存爆掉的终极技巧

慧知开源GOEMS 综合能源管理系统

万圣节快到了：聊得来比装扮更重要，AI 正在悄悄改变节日交流

更多资讯

企业级数据可视化BI 仪表板数据中台监控平台的选择分析

抖音合集批量下载 3 步跑起来：douyin-downloader 无水印保存完整指南

JPG如何转PNG？推荐三个方法，无损画质还免费！

PAS技能建模法：用问题-动作-结果重构个人能力操作系统

VLAN间通信技术：单臂路由与三层交换对比

Seedance 2.5拟真人像提示词四层架构解析

今日更新

MATLAB缩进快捷键与批量格式化实战指南

用Poco实现Qt风格信号与槽的跨平台C++方案

ESXi裸机虚拟化安装指南：从硬件兼容到虚拟机部署

本周精选

金融AI落地指南：从调研报告到技术选型与工程实践

大模型上下文成本与注意力优化技术深度解析——为何O(n²)平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测

基于GMM的语音识别系统原理与MATLAB实现详解

本月热门

我发现了一个新思路：用 Remotion + Claude Code 像写代码一样自动化生成短视频

Windows下 Codex 中 Chrome 和 Computer Use 插件不可用问题排查及解决参考方式：TaoToken 统一 Key 配置与验证

2026 大模型集体涨价：用 Python 做企业 Token 成本测算与选型避坑（附配置）

读完文章，想聊聊您的网站？