Linux 默认权限详解：目录（755）与普通文件（644）权限机制，默认权限由 umask 值决定

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-x`	755	属主可读写执行，其他人只读执行

二、为什么是这个结果？

Linux 的默认权限是由 umask（用户文件创建掩码） 控制的。

计算公式

复制代码

默认权限 = 最大权限 - umask 值

类型	最大权限	默认 umask（root 022，普通用户 002）	计算结果
文件	666（rw-rw-rw-）	022	644（rw-r--r--）
目录	777（rwxrwxrwx）	022	755（rwxr-xr-x）

为什么文件最大是 666 不是 777？

因为新创建的文件默认没有执行权限，这是 Linux 的安全机制（防止恶意可执行文件）。

三、查看和修改 umask

查看当前 umask

bash

bash 复制代码

umask
# 输出：0022（普通用户可能是 0002）

0022 表示：去掉属组的写权限（2），去掉其他用户的写权限（2）。

临时修改 umask（仅当前 Shell 生效）

bash

sql 复制代码

# 设置 umask 为 000（不屏蔽任何权限）
umask 000

# 测试：新创建的文件权限变成 666（rw-rw-rw-）
touch test.txt
ls -l test.txt
# -rw-rw-rw- 1 mumu mumu 0 May 16 10:00 test.txt

永久修改 umask

bash

bash 复制代码

# 编辑 ~/.bashrc（只对当前用户生效）
echo "umask 022" >> ~/.bashrc

# 或编辑 /etc/profile（全局生效，需要 root）
sudo vi /etc/profile

四、验证实验

实验 1：默认创建文件

bash

bash 复制代码

touch default.txt
ls -l default.txt
# -rw-r--r-- 1 mumu mumu 0 May 16 10:00 default.txt
# 644 ✅

实验 2：默认创建目录

bash

bash 复制代码

mkdir default_dir
ls -ld default_dir
# drwxr-xr-x 2 mumu mumu 4096 May 16 10:00 default_dir/
# 755 ✅

实验 3：root 用户 vs 普通用户

bash

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 值	文件权限	目录权限	场景
000	666（rw-rw-rw-）	777（rwxrwxrwx）	完全开放（危险）
002	664（rw-rw-r--）	775（rwxrwxr-x）	同组用户可写（团队项目）
022	644（rw-r--r--）	755（rwxr-xr-x）	默认值（安全）
027	640（rw-r-----）	750（rwxr-x---）	只允许属主和同组访问
077	600（rw-------）	700（rwx------）	完全私有

六、面试常见追问

Q1：为什么新文件没有执行权限？

答：Linux 安全设计。如果需要执行权限，必须手动 chmod +x 赋予。

Q2：umask 002 和 022 有什么区别？

答：002 允许同组用户有写权限（664/775），022 不允许（644/755）。

Q3：如何让所有新文件默认 666？

答：umask 000，但强烈不推荐（安全风险）。

七、针对大数据开发的建议

场景	推荐 umask	原因
单机学习	022（默认）	足够安全
团队开发（共享目录）	002	同组可协作
敏感数据（日志/密钥）	077	仅自己可见

bash

bash 复制代码

# 在大数据团队协作中，经常设置
umask 002

# 然后创建的文件/目录会自动赋予同组写权限
touch team_data.txt
ls -l team_data.txt
# -rw-rw-r-- 1 mumu hadoop 0 ...  属组也有写权限

总结一句话

Linux 默认权限

文件是 644（rw-r--r--），目录是 755（rwxr-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 用户（UID=0） ，是 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

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 denied！
- systemctl 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

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

bash 复制代码

权限： r(4)   w(2)   x(1)
二进制: 1      1      1    = 7 (全开)
二进制: 1      1      0    = 6 (读写)
二进制: 1      0      1    = 5 (读+执行)
二进制: 1      0      0    = 4 (只读)

常见数字组合表（务必记住前三组）

数字	文件权限 (Linux)	目录权限 (Linux)	一句话解释
644	`rw-r--r--`	N/A (目录最少要 755)	文件默认：自己读写，别人只读
755	`rwxr-xr-x`	`rwxr-xr-x`	目录/脚本默认：自己全有，别人看+进
700	`rwx------`	`rwx------`	私有：只有自己全有
600	`rw-------`	N/A	私密文件：如 SSH 私钥
750	`rwxr-x---`	`rwxr-x---`	团队协作：自己和同组能进/改
770	`rwxrwx---`	`rwxrwx---`	团队完全协作：自己和同组全有
777	`rwxrwxrwx`	`rwxrwxrwx`	极度危险：全世界全有

第三，读写执行权限对文件和目录的详细操作

这是最核心的表格，彻底搞懂它，你就算真正入门了。

权限	对文件意味着什么 (针对文件内容)	对目录意味着什么 (针对目录内的文件列表)
读 (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)	源目录：`x` + `w` (删除原文件) 目标目录：`x` + `w` (创建新文件)	本质是在旧目录里"删除"文件名，在新目录里"创建"文件名，不涉及文件内容。
压缩 (tar -czf)	源文件/目录：`r` (读内容) 源目录：`x` (进入)	`tar` 命令要打包，必须能读取所有要打包的原始数据。
解压 (tar -xzf)	当前目录：`x` + `w` (创建新文件/目录)	要在当前目录下"创建"解压出来的文件和文件夹。
上传 (rz)	目标目录：`x` + `w`	要在目标目录里"创建"一个新文件。
下载 (sz)	源文件：`r`	要"读取"源文件的内容，然后发送出去。

一个颠覆你认知的重点：

cp 和 sz 操作的是文件内容 ，所以需要源文件的 r 权限。
mv 和 rm 操作的是目录里的文件名 ，所以需要父目录 的 w 权限，与文件本身的权限无关！

验证实验：

bash

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

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` 权限

验证实验：

bash 复制代码

# 创建一个没有执行权限的脚本
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` 有区别吗？

对比项	`sh`	`bash`
是什么	Bourne Shell（早期 Unix 标准 Shell）	Bourne Again Shell（增强版）
在 Ubuntu 上	`/bin/sh` 是指向 `dash` 的软链接（不是真正的 `sh`）	完整的 bash
语法兼容性	只支持 POSIX 标准语法	支持更多扩展语法（数组、正则等）
日常使用	执行简单脚本	开发复杂脚本（推荐用 `#!/bin/bash`）

在 Ubuntu 上的实际情况：

bash

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.sh`	`sh` 程序	❌ 不需要	脚本是文本输入
`bash script.sh`	`bash` 程序	❌ 不需要	同上
`./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

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 权限的目录：你获得了"进入"的资格。

示例：

bash

bash 复制代码

mkdir 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 权限是多么重要。

这是一个从"直觉"到"理解设计哲学"的飞跃，你正在经历这个重要的过程。

Linux 默认权限详解：目录（755）与普通文件（644）权限机制，默认权限由 umask 值决定