六十天Linux从0到项目搭建（第五天）（file、bash 和 shell 的区别、目录权限、默认权限umask、粘滞位、使用系统自带的包管理工具）

1. file [选项] 文件名

• 用于确定文件类型的实用工具。它会通过分析文件内容（而不仅仅是文件扩展名）来判断文件的实际类型

示例输出解析

$ file /bin/bash
/bin/bash: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 3.2.0, BuildID[sha1]=..., stripped

这段输出告诉我们：

• 这是一个 ELF 格式的可执行文件
• 64位架构，x86-64指令集
• 动态链接
• 为 GNU/Linux 系统编译
• 已被剥离调试符号

2. bash 和 shell 的区别

• Shell：是用户与操作系统内核交互的命令行界面，是统称

• Bash (Bourne Again Shell)：是Shell的一种具体实现，是Linux系统中最常用的shell

类比法就是

• Shell 是「智能家居中控系统」的通用标准（比如所有品牌都支持的 Zigbee 协议）。

• Bash 是某品牌的中控系统（比如小米 HomeKit），功能更强大、用户最多，但本质仍是 Shell 的一种实现

3 目录权限的深度解析（从文件系统角度理解）

1. 进入目录（cd）需要什么权限？

必须权限：x（执行权限）

• 为什么？

  • 目录的本质是一个记录子文件位置的特殊文件，x 权限控制你能否“执行”这个目录（即访问其内容）。

  • 类比：进入房间需要钥匙（x），即使你知道房间里有东西（r），没有钥匙也进不去。

验证：

chmod -x dir/      # 移除 x 权限
cd dir/            # 报错：Permission denied

---

2. 目录的 r（读权限）代表什么？

作用：允许查看目录下的文件名和基础属性（如 ls）

• 无 r 权限时：

  • ls dir/ → 报错 Permission denied，但已知完整路径的文件仍可访问！

  • 文件系统原理：

    • r 仅控制读取目录条目（dirent 结构），不影响通过完整路径访问文件。

验证：

chmod -r dir/      # 移除 r 权限
ls dir/            # 失败
cat dir/known_file # 成功（需有文件本身的 r 权限）

---

3. 目录的 w（写权限）代表什么？

作用：允许修改目录内容（创建/删除/重命名文件）

• 无 w 权限时：

  • touch dir/new_file → 报错 Permission denied

  • 关键点：删除文件需要父目录的 w，而非文件本身的权限！

文件系统原理：

• 目录的 w 权限控制其 inode 中“子文件列表”的修改权。

验证：

chmod -w dir/          
touch dir/new_file    # 失败
rm dir/old_file      # 失败（即使 old_file 可写）

---

4. 目录权限的底层逻辑（文件系统视角）

权限	对应操作	影响的文件系统操作
r	读取目录条目	readdir() 系统调用
w	修改目录条目	unlink()（删除）、rename()（重命名）
x	进入目录/访问子文件元数据	open() 文件时需要检查父目录的 x

为什么这样设计？

• 安全分层：防止用户绕过权限直接操作文件（如通过 rm 删除只读文件）。

• 性能优化：x 权限避免频繁检查子文件权限。

---

5. 特殊场景与误区

(1) 无 r 但能访问已知文件

chmod -r dir/
cat dir/secret.txt  # 成功（若 secret.txt 有 r 权限）

• 原因：文件系统通过完整路径直接定位 inode，不依赖父目录的 r。

(2) 无 x 但能 stat 文件

chmod -x dir/
stat dir/file      # 失败！需父目录 x 权限

• 原因：访问文件元数据（如大小、时间）需要父目录的 x。

(3) 目录粘滞位（t）

chmod +t /tmp      # 仅文件所有者可删除自己的文件

• 用途：共享目录（如 /tmp）中防止他人删除你的文件。

---

6. 总结：目录权限三要素

权限	关键作用	无权限时的表现
r	查看目录内容（文件名）	ls 失败，但已知路径可访问文件
w	修改目录内容（增删改文件）	无法创建/删除/重命名文件
x	进入目录或访问子文件元数据	cd 和 stat 均失败

4. 文件与目录默认权限的底层逻辑（umask 机制详解）

1. 默认权限的起点

• 普通文件：系统设定的起始权限是 666（-rw-rw-rw-）

  • 所有用户可读、可写，但不可执行（安全考虑，避免随意运行未知文件）。

• 目录：系统设定的起始权限是 777（drwxrwxrwx）

  • 所有用户可读、写、进入（目录需要 x 权限才能访问内容）。

 为什么目录比文件多 x？

• 文件 x 是“执行”，目录 x 是“进入/搜索”，二者含义不同。

• 目录必须允许 x，否则无法 cd 或访问子文件。

---

2. 权限掩码（umask）的作用

• umask 是系统的一个权限过滤器，用于从起始权限中屏蔽某些权限。

• 规则：
  最终权限 = 起始权限 & (~umask)
  （即从起始权限中移除 umask 指定的权限）

查看当前 umask：

umask      # 默认输出（如 0022）
umask -S   # 符号格式（如 u=rwx,g=rx,o=rx）

---

3. 默认 umask 值（常见场景）

• Linux 普通用户：0002 → 屏蔽 other 的 w 权限。

• Linux root 用户：0022 → 屏蔽 group 和 other 的 w 权限。

计算示例：

1. 普通文件（起始 666）

   • umask 022 → 移除 group 和 other 的 w

     666:  rw- rw- rw-  
     & ~022: rw- r-- r--  
     -------------------  
     644:  rw- r-- r--  

   • 实际权限：-rw-r--r--（所有者可读写，其他人只读）。

2. 目录（起始 777）

   • umask 022 → 移除 group 和 other 的 w

     777:  rwx rwx rwx  
     & ~022: rwx r-x r-x  
     -------------------  
     755:  rwx r-x r-x  

   • 实际权限：drwxr-xr-x（所有者全权，其他人不可修改目录内容）。

---

4. 为什么普通文件默认 664（而非 644）？

• 现代 Linux 发行版（如 Ubuntu）默认 umask 为 0002（而非 0022）：

  • 普通用户创建文件时：

    666 & ~002 = rw- rw- r-- → 664  

  • 目的：允许同组用户协作编辑文件（适合多用户环境）。

验证：

umask 0002    # 临时设置 umask
touch test.txt
ls -l test.txt  # 输出 -rw-rw-r--

---

5. 修改 umask 的注意事项

• 临时修改（仅当前会话有效）：

  umask 0027   # 屏蔽 group 的 w 和 other 的所有权限

• 永久修改：
  将 umask 002 添加到 ~/.bashrc 或 /etc/profile。

• 安全建议：

  • root 用户应保持 umask 022 或更严格（如 027）。

  • 共享目录可设 umask 002（组内协作）。

---

6. 特殊场景

• 可执行文件：

  • 若文件本身需要执行权限（如脚本），需手动添加 x：

    chmod +x script.sh

• 目录的粘滞位（t）：

  • 设置后（如 /tmp），即使有 w 权限，用户也只能删除自己的文件：

    chmod +t /shared_dir

---

总结：权限设计的核心逻辑

对象	起始权限	umask 作用	常见默认权限
普通文件	666	移除 w（防止误改）	664（用户）、644（root）
目录	777	保留 x（确保可进入）	775（用户）、755（root）

关键点：

1. umask 不添加权限，只从起始权限中屏蔽。

2. 目录必须保留 x，否则无法访问子文件。

3. 权限设计遵循最小特权原则，平衡安全与便利。

5. 粘滞位（Sticky Bit）详解：保护共享目录中的用户文件

---

1. 问题背景

• 共享目录场景：

  • 由 root 创建一个目录（如 /shared_tmp），供所有用户存放临时文件。
  • 目录权限通常为 777（drwxrwxrwx），允许所有用户读写。

• 风险：

  • 虽然文件受权限约束（如 -rw-r--r--），但任何有目录 w 权限的用户都能删除他人的文件！
  • 原因：Linux 中，删除文件需要父目录的 w 权限，而非文件本身的权限。

---

2. 粘滞位的作用

• 粘滞位（Sticky Bit） 是一种特殊的目录权限，设定后：

  • 用户只能删除自己创建的文件，即使目录是 777。
  • 典型应用：/tmp 目录（所有用户可写，但无法随意删别人的文件）。

查看 /tmp 的权限：

ls -ld /tmp      # 输出示例：drwxrwxrwt

注意最后的 t，表示粘滞位已设置。

---

3. 如何设置粘滞位？

方法 1：符号模式（推荐）

chmod +t /shared_dir

方法 2：数字模式

chmod 1777 /shared_dir   # 1xxx 中的 1 表示粘滞位

验证：

ls -ld /shared_dir      # 输出应包含 `... rwt` 或 `... rwT`

• t：粘滞位 + 其他人有 x 权限。
• T：粘滞位 + 其他人无 x 权限（罕见，可能配置错误）。

---

4. 粘滞位的规则

操作	无粘滞位（普通 777 目录）	有粘滞位（1777 目录）
用户创建文件	可以	可以
用户删除自己的文件	可以	可以
用户删除他人文件	可以（只要有目录 w 权限）	禁止
root 用户删除文件	可以	可以（root 不受限制）

关键点：

• 粘滞位仅影响文件删除，不影响读取或修改文件内容（文件自身的 rw 权限仍有效）。

• 谁可以删除文件？

  • 文件所有者、目录所有者、root。

---

5. 为什么需要粘滞位？

• 共享目录的权限矛盾：

  • 若目录无 w 权限 → 用户无法创建文件。

  • 若目录有 w 权限 → 用户可删除他人文件。

• 粘滞位的平衡：

  • 允许所有人创建文件（777），但禁止随意删除他人文件（+t）。

---

6. 实际应用示例

场景：创建一个共享临时目录 /shared_tmp，要求：

1. 所有用户可读写。

2. 用户只能删除自己的文件。

步骤：

# 1. 创建目录并设置权限
sudo mkdir /shared_tmp
sudo chmod 1777 /shared_tmp   # 或 chmod a+rwxt /shared_tmp# 2. 验证权限
ls -ld /shared_tmp           # 应显示 drwxrwxrwt# 3. 测试（用户A和用户B）
# 用户A创建文件
touch /shared_tmp/userA_file# 用户B尝试删除（失败）
rm /shared_tmp/userA_file    # 报错：Operation not permitted

---

7. 常见问题

Q1：粘滞位对文件有效吗？

• 无效！粘滞位仅适用于目录。对文件设置 +t 会被忽略（显示为 T）。

Q2：为什么 /tmp 默认有粘滞位？

• 因为 /tmp 是系统级共享目录，需防止用户互相删除文件导致安全问题。

Q3：如何移除粘滞位？

chmod -t /shared_dir

---

总结：粘滞位的核心逻辑

权限	作用
目录 w	控制能否在目录内创建/删除文件。
粘滞位 t	限制删除权限（仅允许所有者删除）。

6. 使用系统自带的包管理工具（推荐）

• 在 Linux 服务器上安装软件，主要通过 包管理工具 来实现，类似于手机上的应用商店。以下是详细的操作流程和常见方法：

不同的 Linux 发行版有不同的包管理工具，最常见的是：

Linux 发行版	包管理工具	安装命令示例
Ubuntu/Debian	apt (Advanced Package Tool)	sudo apt install 软件名
CentOS/RHEL	yum 或 dnf	sudo yum install 软件名 或 sudo dnf install 软件名
Arch Linux	pacman	sudo pacman -S 软件名
openSUSE	zypper	sudo zypper install 软件名

示例（Ubuntu/Debian 系统）

# 1. 更新软件包列表（获取最新软件信息）
sudo apt update# 2. 安装软件（如 nginx）
sudo apt install nginx# 3. 卸载软件
sudo apt remove nginx

 优点：

• 自动解决依赖关系（类似手机应用商店一键安装）。

• 官方软件库，安全稳定。