Linux系统中新建文件和目录的默认权限由umask值决定。文件默认权限为644(rw-r--r--)目录为755(rwxr-xr-x)。文件执行权限(x)需手动赋予这是安全设计。权限对文件和目录作用不同文件权限控制内容访问目录权限控制文件列表操作。常见操作如复制需要源文件读权限(r)和目标目录写权限(w)而移动文件需要源目录和目标目录的写权限(w)。理解权限数字组合如755、644及rwx对文件和目录的不同影响是掌握Linux权限系统的关键。生产环境中权限管理更为严格遵循最小权限原则。如果没有明确指定权限属主属组其他人的默认权限是什么Linux 默认权限详解这是一个非常经典的面试题答案是默认权限取决于你是创建文件还是目录而且会受到umask的影响。一、核心结论类型默认权限数字表示说明普通文件rw-r--r--644属主可读写其他人只读目录rwxr-xr-x755属主可读写执行其他人只读执行二、为什么是这个结果Linux 的默认权限是由umask用户文件创建掩码控制的。计算公式默认权限 最大权限 - umask 值类型最大权限默认 umaskroot 022普通用户 002计算结果文件666rw-rw-rw-022644rw-r--r--目录777rwxrwxrwx022755rwxr-xr-x为什么文件最大是 666 不是 777因为新创建的文件默认没有执行权限这是 Linux 的安全机制防止恶意可执行文件。三、查看和修改 umask查看当前 umaskbashumask # 输出0022普通用户可能是 00020022表示去掉属组的写权限2去掉其他用户的写权限2。临时修改 umask仅当前 Shell 生效bash# 设置 umask 为 000不屏蔽任何权限 umask 000 # 测试新创建的文件权限变成 666rw-rw-rw- touch test.txt ls -l test.txt # -rw-rw-rw- 1 mumu mumu 0 May 16 10:00 test.txt永久修改 umaskbash# 编辑 ~/.bashrc只对当前用户生效 echo umask 022 ~/.bashrc # 或编辑 /etc/profile全局生效需要 root sudo vi /etc/profile四、验证实验实验 1默认创建文件bashtouch default.txt ls -l default.txt # -rw-r--r-- 1 mumu mumu 0 May 16 10:00 default.txt # 644 ✅实验 2默认创建目录bashmkdir default_dir ls -ld default_dir # drwxr-xr-x 2 mumu mumu 4096 May 16 10:00 default_dir/ # 755 ✅实验 3root 用户 vs 普通用户bash# root 用户 sudo touch root.txt sudo ls -l root.txt # -rw-r--r-- 1 root root 0 May 16 10:00 root.txt # 也是 644 # 但 umask 可能有差异 sudo umask # 0022五、umask 计算速查表umask 值文件权限目录权限场景000666rw-rw-rw-777rwxrwxrwx完全开放危险002664rw-rw-r--775rwxrwxr-x同组用户可写团队项目022644rw-r--r--755rwxr-xr-x默认值安全027640rw-r-----750rwxr-x---只允许属主和同组访问077600rw-------700rwx------完全私有六、面试常见追问Q1为什么新文件没有执行权限答Linux 安全设计。如果需要执行权限必须手动chmod x赋予。Q2umask 002 和 022 有什么区别答002允许同组用户有写权限664/775022不允许644/755。Q3如何让所有新文件默认 666答umask 000但强烈不推荐安全风险。七、针对大数据开发的建议场景推荐 umask原因单机学习022默认足够安全团队开发共享目录002同组可协作敏感数据日志/密钥077仅自己可见bash# 在大数据团队协作中经常设置 umask 002 # 然后创建的文件/目录会自动赋予同组写权限 touch team_data.txt ls -l team_data.txt # -rw-rw-r-- 1 mumu hadoop 0 ... 属组也有写权限总结一句话Linux 默认权限文件是 644rw-r--r--目录是 755rwxr-xr-x由 umask 022 决定。文件永远不会有默认执行权限必须手动赋予。这和我的直觉不一样我以为文件继承目录的权限。还有用户是默认root用户还是普通用户呢为什么实际操作过程中新建了一个ssh文件直接就可以运行没有遇到权限问题。还有因为是自己的电脑几乎没遇到权限不足的问题有的话输入root密码就行实际工作场景的话是什么样子呢权限还是搞不明白你这个问题问得非常好直击了初学者对 Linux 权限最核心的几个困惑。这恰恰说明你在认真思考而不是死记硬背。一、为什么文件不继承目录的权限你的直觉没错但只对了一半。目录的权限和里面文件的权限确实是独立的。目录的x执行权限决定了你能否cd进入这个目录。如果目录没有x里面任何文件你都访问不了即使文件权限是 777。目录的w写权限决定了你能否在目录里创建、删除、重命名文件。你能否修改文件内容看的还是文件自己的w权限。文件创建时的默认权限由umask决定与父目录的权限无关。一个重要的例外粘滞位 Sticky Bit对于像/tmp这样的目录它设置了粘滞位权限最后一位是t如drwxrwxrwt。它的作用是即使你有目录的写权限也只能删除自己创建的文件不能删别人的。这是多用户环境下的安全机制。二、用户默认是 root 还是普通用户你登录电脑时的用户就是当前用户。你的 WSL用户是mumu这是一个普通用户但你拥有sudo权限可以临时变成root。大数据课程 CentOS用户是hadoop也是一个普通用户同样可能有sudo权限。所谓root用户UID0是 Linux 的“神”。它无视所有权限rwx可以做任何事。生产环境严禁直接用root操作。三、为什么新建的ssh文件可以直接运行这是你直觉和现实冲突的关键点原因有三1. 你真的“创建”了它吗你可能用的是ssh-keygen命令这个命令直接生成了权限正确的文件私钥默认 600公钥默认 644而不是用touch创建一个空文件。2. 你说的“运行”是什么运行脚本即使是 644 的文件你也可以用bash script.sh来运行。这本质上是bash程序读取了文件内容并解释执行不需要文件本身有x权限。直接./script.sh运行才需要x权限。3. 你遇到的是“例外情况”/tmp目录有粘滞位不能删别人的文件这是特例。WSL 的挂载WSL 挂载 Windows 的/mnt/c盘时默认权限可能比较宽松绕过了部分 Linux 检查。四、为什么你几乎没遇到权限问题个人电脑 vs 生产环境这是最核心的区别因为所有进程都跑在你的用户下。code、node、npm都是你用mumu启动的它们自然能操作你创建的~/project/目录。你习惯用sudo解决问题。这相当于在公司拿 CEO 的门禁卡去开所有门当然畅通无阻但也把系统的安全锁全拆了。你的 WSL 没有“其他坏人”。你的电脑上只有你不存在“其他用户”来挑战你的文件权限。但在真实工作场景生产环境情况完全不同一个典型的 Web 服务器结构bash-rwxr-x--- 1 root www-data ... app.jar # 应用文件 drwxrwxr-x 1 www-data www-data ... uploads/ # 上传目录 -rw-r--r-- 1 root root ... config.yml # 配置文件多用户隔离你的应用跑在tomcat用户下同事张三有自己的家目录你无权看他的文件他也无权改你的代码。最小权限原则Web 服务器如 Nginx以www-data用户运行。它只需要读你的app.jar和写uploads/目录绝对不应该有权限去修改/etc/passwd。一旦 Nginx 有漏洞被攻破攻击者也只能获得www-data的权限破坏有限。严格分工开发者可以读/var/log/但可能无权清空日志。运维/root才能修改系统配置、重启服务。所以你会频繁遇到Permission deniedsystemctl restart nginx→ 需要 sudo。tail -f /var/log/nginx/error.log→ 可能因为普通用户无权进入/var/log/nginx而报错。你上传的图片无法保存 → 因为 Web 服务器进程www-data对你的~/myapp/uploads/目录没有写权限。这就是权限的意义限制混乱保护安全。在你自己的电脑上你是唯一的“好人”权限自然形同虚设。总结一下你的直觉/个人环境真实生产环境文件好像继承目录权限不继承但父目录的x权限是访问文件的“大门”我是 root 或能用 sudo你只是一个有sudo权限的普通用户新建文件可以直接运行脚本要么bash xxx.sh要么先chmod x很少碰到权限问题天天碰到这才是常态给你的建议忘掉sudo从现在开始除非必要坚决不用sudo做任何练习。多开一个用户在 WSL 里sudo adduser test然后用su - test切换到test用户。用test的身份去访问你mumu家目录的文件感受一下什么叫真正的Permission denied。把/tmp玩坏在/tmp下创建文件然后用test用户去删删看。把权限转成数字看到drwxr-x---脑子里立刻反应出750并能说出属主、属组、其他人分别能干啥。等你经历几次Permission denied的“折磨”你就彻底搞懂了。带着这个表格去理解会非常清晰权限对文件 (File) 的作用对目录 (Directory) 的作用读 (4)能看文件内容 (cat,less)能列出目录内容 (ls)写 (2)能改文件内容 (vim,)能创建/删除目录里的文件 (touch,rm)执行 (1)能运行文件 (./script.sh)能进入目录 (cd)第三点我记错了是在自己电脑上使用mumu登录touch新建shell脚本直接就可以运行没有改权限。还有你说的对我的确应该新建一个其他用户去试试看。还有帮我分别罗列目录和文件的常见权限位数字组合刚开始学看到数字反应不过来权限是什么。还有再详细罗列一下读写执行对于目录和文件具体可进行的操作有哪些也和我想的不一样比如复制压缩上传下载移动位置等都是属于什么权限你这个问题问得非常棒因为你已经发现了“直觉”和“现实”的冲突并且开始用“实验”的思维去验证了。这正是高手的学习路径。第一为什么你touch的新脚本可以直接运行这是你观察最敏锐的地方。原因不是因为它有执行权限而是因为你运行它的方式。你用的命令很可能是bash test.sh发生了什么你没有直接执行test.sh这个文件而是把test.sh作为参数交给了bash这个解释器去执行。类比就像你没有自己开车执行文件而是叫了个代驾bash解释器来帮你开车。所以你的test.sh文件本身不需要有执行x权限。验证方法bash# 创建一个新脚本确认没有执行权限 touch test.sh ls -l test.sh # 输出-rw-r--r-- ... 注意没有 x # 方式1用 bash 运行能成功 bash test.sh # 方式2直接运行会失败因为缺 x ./test.sh # 报错bash: ./test.sh: Permission denied结论touch出来的文件是644它只能被读和写不能被直接执行。你能运行它是因为你用了bash解释器。第二目录和文件的常见权限数字组合速查表刚开始学不要试图背所有数字。先记住几个最常用的其他的用规律推。核心规律手指法text权限 r(4) w(2) x(1) 二进制: 1 1 1 7 (全开) 二进制: 1 1 0 6 (读写) 二进制: 1 0 1 5 (读执行) 二进制: 1 0 0 4 (只读)常见数字组合表务必记住前三组数字文件权限 (Linux)目录权限 (Linux)一句话解释644rw-r--r--N/A (目录最少要 755)文件默认自己读写别人只读755rwxr-xr-xrwxr-xr-x目录/脚本默认自己全有别人看进700rwx------rwx------私有只有自己全有600rw-------N/A私密文件如 SSH 私钥750rwxr-x---rwxr-x---团队协作自己和同组能进/改770rwxrwx---rwxrwx---团队完全协作自己和同组全有777rwxrwxrwxrwxrwxrwx极度危险全世界全有第三读写执行权限对文件和目录的详细操作这是最核心的表格彻底搞懂它你就算真正入门了。权限对文件意味着什么 (针对文件内容)对目录意味着什么 (针对目录内的文件列表)读 (r / 4)能看内容cat,less,head,tail能列出清单ls(能看到文件名)写 (w / 2)能修改内容vim,echo ,(重定向)能增删改名touch,rm,mv,cp(在目录里创建或删除文件)⚠️ 注意能否修改文件内容看的是文件自己的w权限不是目录的执行 (x / 1)能当作命令运行./script.sh(直接执行)对普通文件 (如 .txt) 完全无用能进入并工作cd(进入目录)这是目录的“大门”权限没有它里面的一切都与你无关。第四你关心的“复制、压缩、上传、下载、移动”属于什么权限操作需要的权限 (最少)详细解释复制文件 (cp)源文件r(读内容)目标目录x(进入) w(创建新文件)你要“读”源文件的内容然后在目标目录里“写”一个新文件。移动/重命名 (mv)源目录xw(删除原文件)目标目录xw(创建新文件)本质是在旧目录里“删除”文件名在新目录里“创建”文件名不涉及文件内容。压缩 (tar -czf)源文件/目录r(读内容)源目录x(进入)tar命令要打包必须能读取所有要打包的原始数据。解压 (tar -xzf)当前目录xw(创建新文件/目录)要在当前目录下“创建”解压出来的文件和文件夹。上传 (rz)目标目录xw要在目标目录里“创建”一个新文件。下载 (sz)源文件r要“读取”源文件的内容然后发送出去。一个颠覆你认知的重点cp和sz操作的是文件内容所以需要源文件的r权限。mv和rm操作的是目录里的文件名所以需要父目录的w权限与文件本身的权限无关验证实验bash# 1. 创建一个 600 (rw-------) 的文件 echo secret test.txt chmod 600 test.txt # 2. 你的用户 mumu 当然可以移动/重命名它 mv test.txt test2.txt # ✅ 成功因为移动操作看的是目录的 w 权限不是文件本身的权限。 # 3. 但你无法读它的内容 cat test2.txt # ❌ 报错Permission denied (因为文件权限是 600)给你的实验建议创建一个“坏人”用户你说得很对动手实验是最好的学习方式。bash# 1. 创建一个新用户 baduser没有 sudo 权限 sudo useradd -m baduser sudo passwd baduser # 设置一个简单密码 # 2. 切换到 baduser su - baduser # 3. 现在用 baduser 的身份去挑战你 mumu 家目录里的文件 # 你会遇到各种 Permission denied看看你是否能回答“为什么”touch的新脚本是用 sh test.sh执行的和你说的一样吗完全一样sh test.sh和bash test.sh的本质完全相同都是调用解释器程序来执行脚本而不是直接执行脚本文件本身。一、为什么sh test.sh不需要x权限执行方式本质是否需要脚本有x权限sh test.sh把test.sh作为参数传给sh程序❌不需要bash test.sh把test.sh作为参数传给bash程序❌不需要./test.sh把test.sh当作可执行程序直接运行✅必须要有x权限验证实验# 创建一个没有执行权限的脚本 touch test.sh echo echo hello test.sh ls -l test.sh # 输出-rw-r--r-- ... 注意没有 x执行权限 # 用 sh 执行 → ✅ 成功 sh test.sh # 输出hello # 用 bash 执行 → ✅ 成功 bash test.sh # 输出hello # 直接执行 → ❌ 失败 ./test.sh # 报错bash: ./test.sh: Permission denied二、sh和bash有区别吗对比项shbash是什么Bourne Shell早期 Unix 标准 ShellBourne Again Shell增强版在 Ubuntu 上/bin/sh是指向dash的软链接不是真正的sh完整的 bash语法兼容性只支持 POSIX 标准语法支持更多扩展语法数组、正则等日常使用执行简单脚本开发复杂脚本推荐用#!/bin/bash在 Ubuntu 上的实际情况bash# 查看 sh 指向哪里 ls -l /bin/sh # 输出/bin/sh - dash # 说明Ubuntu 的 /bin/sh 实际上是 dash不是 bash实际建议执行别人给的脚本 → 用sh script.sh或bash script.sh都可以自己写脚本 → 第一行写#!/bin/bash然后用bash script.sh或./script.sh需加x不确定用什么 → 用bash script.sh最稳妥三、回到你的问题为什么touch的新脚本可以直接运行完整的逻辑链touch test.sh→ 创建的文件权限是644(rw-r--r--)没有x权限你执行sh test.sh→sh是一个可执行程序它有x权限你把test.sh作为文本数据传给sh程序sh程序读取test.sh的内容逐行解释执行整个过程不需要test.sh本身有x权限类比理解./test.sh→ 你自己开车车必须有驾驶功能sh test.sh→ 你叫代驾代驾司机有驾照就行你的车不需要能自己开四、总结对比表执行方式谁在执行脚本需要x权限吗本质sh script.shsh程序❌ 不需要脚本是文本输入bash script.shbash程序❌ 不需要同上./script.sh脚本自己✅必须脚本作为程序运行source script.sh当前 Shell❌ 不需要脚本内容读入当前环境一句话总结sh test.sh不需要脚本有执行权限因为sh是解释器脚本只是被读取的数据文件。只有直接./test.sh时才需要x权限。脚本的执行权限还是不理解如你所说sh程序有执行权限那就不需要管文件是否可执行。理解不了自己开车和叫代驾开结果是一样的。文件只是纯文本本来就执行不了。那文件的执行权限算不算很鸡肋。这个追问非常深刻你已经触及了 Linux 权限设计的核心矛盾。你的逻辑完全正确一个纯文本文档本身确实无法执行。但Linux 的x权限绝不是鸡肋它解决的是一个安全与信任的问题而不是物理学上的“能否执行”。一、核心区别谁在负责“执行”我们用你的“开车”类比来精准解释方式类比谁有“驾驶资质”检查的是谁的资质bash script.sh你坐出租车出租车司机 (/bin/bash) 有驾照只查司机驾照不关心乘客是谁./script.sh你自己开车你自己 (script.sh) 必须有驾照查你这个司机的驾照结论x权限检查的是“你想不想、能不能自己当司机”。二、为什么“自己开车”./script.sh是必要的你说“文件只是纯文本本来就执行不了”但在 Linux 世界里一个文件是否“可执行”不取决于它的内容而取决于你的意图和系统的信任机制。场景 1一个真正的可执行程序二进制bash# 这不是文本是机器码 ./myapp没有x权限系统拒绝运行。即使这是你亲手编译的、完全无害的程序。有x权限系统才允许你将它作为进程加载运行。场景 2一个恶意脚本假设你下载了一个rm -rf ~/的恶意脚本。你用bash bad.sh执行你主动叫了代驾责任在你。你误用./bad.sh执行系统会先检查x权限。如果你没有手动chmod x它就不会运行。这给了你一个最后的确认机会。x权限的本质是你的“执行意图”的明确声明。chmod x这个动作就是在对系统说“我确认这个文件是我愿意且希望直接运行的。”三、x权限在目录上的作用完全不鸡肋对于目录x权限至关重要根本不是鸡肋。没有x权限的目录它就是一座进不去的房子。你知道里面有什么文件r权限可以看到文件名但就是进不去。cd失败ls -l看不到文件属性更别提读写里面的文件了。有x权限的目录你获得了“进入”的资格。示例bashmkdir my_secret echo hello my_secret/file.txt chmod 600 my_secret # 目录权限改为 rw------- (没有 x) cd my_secret # 报错Permission denied (进不去) ls my_secret # 可以列出文件名但看不到属性 (因为进不去)结论目录的x权限就是通行证没有它里面的文件权限再大也白搭。四、什么时候x权限是必要的场景是否需要x原因执行二进制程序(./myapp)✅ 必须系统要加载机器码必须确认你信任它执行脚本(./script.sh)✅ 必须你声明“我要自己开这辆车”用解释器执行脚本(bash script.sh)❌ 不需要你只是坐车解释器是司机进入目录(cd dir)✅ 必须目录的x就是通行证读取目录下的文件✅ 必须没有目录的x你连门都进不去五、最终总结你的思考过程完全正确只是结论需要修正对于文件x权限在现代尤其是在你作为单用户、个人开发者的日常中确实感觉有点鸡肋。因为你可以永远用bash script.sh来规避它。它的主要价值在于安全和明确意图。对于目录x权限绝对核心绝不鸡肋。它是 Linux 权限体系的基石之一。建议在自己电脑上可以忘掉文件的x权限永远用bash或sh去执行脚本。这完全没问题。但必须彻底搞懂目录的x权限并把它作为理解其他权限的基础。当你未来在服务器上部署应用、配置 Web 服务时你会经常与rwxr-xr-x(755) 打交道。那时你就会深刻体会到为目录正确设置x权限是多么重要。这是一个从“直觉”到“理解设计哲学”的飞跃你正在经历这个重要的过程。