各位码农、运维大爷、还有那些立志要成为系统架构师的同学们，大家晚上好！
今天我们不聊虚的，不聊怎么在相亲网站上用 PHP 写个奇葩程序，也不聊怎么用 Python 做个爬虫把隔壁公司的数据库搬空。今天，我们要聊的是一场“生死时速”——一场关于文件系统保卫战。
想象一下这个场景：
那是凌晨三点，你正戴着耳机，准备享受一段宁静的独处时光，你的手机突然震动了一下。不是老板发来的“那个需求怎么还没做完”，而是客户在群里咆哮：“我们的网站挂了！首页全是乱码！刚才好像有个攻击者在往里面塞什么东西！”
你爬起来，打开服务器，查看日志，发现了一个让你心惊肉跳的弹窗：Permission denied（权限拒绝）。再仔细一看，好家伙，代码库里多了一个叫 shell.php 的文件，里面的内容大概是 <?php system($_GET['cmd']); ?>。
这就是经典的 Webshell 入侵。对于 PHP 这种“胶水语言”来说，它太灵活了，灵活到有时候像是一匹脱缰的野马。如果你的 PHP 容器里，文件系统是“敞开大门”的，那么这个野马就能跑进你的羊圈，把羊（数据）全吃了。
今天，我就要教大家如何给 PHP 容器穿上“防弹衣”，使用 Read-only Rootfs（只读根文件系统），从物理层面对文件系统进行加固，把那些试图篡改代码的攻击者挡在门外。
准备好了吗？我们开始上课！
第一章：你的容器是个“神偷”？
在 Docker 这个神奇的世界里，默认的文件系统行为就像是一个好脾气的房东，虽然不想让你砸墙，但如果你想在他家安个摄像头（写入文件），他通常会说：“行吧，随便你。”
让我们看看 Docker 默认的架构。当你运行一个 PHP 容器时，底层其实发生了两件事：
- 镜像层：这是只读的。它包含了你的 Nginx、PHP-FPM、以及你辛苦写的业务代码。这部分是神圣不可侵犯的。
- 容器层：这是可写的。当你修改了配置文件，或者上传了一张图片，或者……有人上传了一个 Webshell，这些操作都会发生在这里。
这层可写容器层，就是你今天要“锁起来”的地方。如果你不锁，攻击者一旦突破了你的 PHP 代码漏洞，他就能通过文件上传或者命令执行漏洞，把这个可写层当成自家的后花园。
我们的目标，就是使用 Read-only Rootfs 技术，将容器的根目录 / 设定为只读。
第二章：物理隔离的艺术
要在 Docker 里实现只读根文件系统，这听起来像是要把房子的承重墙焊死。你不能把一切都锁死，否则 PHP 进程连个临时缓存都存不了，那就没法跑了。
这就涉及到了一个高级概念：挂载点。
Linux 的文件系统就像是一个俄罗斯套娃，最外面是根目录 /。我们通常的做法是：
/是只读的（锁住的保险库）。/var/log是可写的（敞开的垃圾桶）。/tmp是可写的（流动的河水）。
这就是“分区隔离”策略。我们要构建一个物理层级的堡垒：核心代码区（只读） + 运行时缓冲区（读写）。
第三章：实战——如何构建坚不可摧的 PHP 容器？
现在，让我们拿出手术刀，开始解剖这个容器。
第一步：Dockerfile——基础的打磨
首先，我们从一个标准的 PHP 镜像开始。这里我们使用 PHP 8.1 的 FPM 版本。
# 这里的 FROM 就像是搬进新房子，结构都是现成的
FROM php:8.1-fpm
# 安装一些必要的系统工具，虽然我们想把它锁起来，但有时候为了安全，得先装个锁
RUN apt-get update && apt-get install -y
libpng-dev
&& rm -rf /var/lib/apt/lists/*
# 编译 PHP 扩展，这步通常需要写权限，完成后就完成了
RUN docker-php-ext-install gd pdo_mysql
# 这里有个关键点：我们通常在镜像构建时设置好权限，容器运行时就不动了
# 但为了演示 Read-only 的威力，我们主要在 docker-compose.yml 里动手脚第二步：启动脚本——聪明的守门人
如果只是简单地在 Docker 命令行加个 --read-only 参数，容器启动就会报错，因为 PHP 需要写 /var/run/php-fpm.pid 或者 /tmp。所以，我们需要一个启动脚本来处理这些“敏感部位”。
创建一个名为 entrypoint.sh 的文件：
#!/bin/sh
set -e
# 1. 初始化一些必须可写的目录
# 即使根目录是只读的，我们也要把这些目录“挖”出来，变成可写的
# 创建日志目录
mkdir -p /var/log/php-fpm
chmod 755 /var/log/php-fpm
# 创建会话目录（这对 PHP Session 非常重要）
mkdir -p /var/lib/php/session
chmod 777 /var/lib/php/session
# 创建运行时目录（存放 PID 之类的）
mkdir -p /var/run/php-fpm
chmod 755 /var/run/php-fpm
# 2. 设置 /tmp 目录的 Sticky Bit
# 这是一个安全特性，只有文件的所有者才能删除它
chmod 1777 /tmp
# 3. 挂载卷
# 这是物理层加固的核心：将宿主机的卷挂载到容器内的这些特定位置
# 这样，即使容器想写文件，也必须通过宿主机（你）控制，而且不会污染镜像本身
# 挂载日志卷：确保日志不会把容器磁盘撑爆
if [ ! -d /var/log/php-fpm ]; then
# 如果不存在（初次运行），就创建
mkdir -p /var/log/php-fpm
fi
# 挂载 PHP Session 卷
if [ ! -d /var/lib/php/session ]; then
mkdir -p /var/lib/php/session
fi
# 注意：在实际生产中，你应该使用 -v 参数在 docker-compose 中挂载，
# 但这个脚本可以作为兜底，防止容器因为权限问题直接崩溃。
# 4. 启动 PHP-FPM
echo "Starting PHP-FPM in Read-only Rootfs mode..."
exec "$@"第三步：Docker Compose——连接灵魂的纽带
这是重头戏。在这个 YAML 文件里，我们要明确告诉 Docker：把根目录锁死，然后把特定的“透气口”打开。
version: '3.8'
services:
php-app:
# 使用刚才构建的镜像
image: my-secure-php:latest
# --- 核心魔法：Read-only 根文件系统 ---
# 这个参数告诉内核：除了我们通过挂载指定的位置，任何地方都别想写！
read_only: true
# 禁用所有网络功能（可选，视安全需求而定，这里为了演示先不禁用，否则你看不到报错）
# cap_drop:
# - ALL
# cap_add:
# - CHOWN
# - DAC_OVERRIDE
# --- 物理层加固：挂载卷策略 ---
volumes:
# 1. 挂载代码目录（关键！确保代码不可篡改）
# 将宿主机的代码目录挂载为只读卷
- ./code:/var/www/html:ro
# 2. 挂载日志目录（防止磁盘填满，防止日志篡改）
# 使用匿名卷或者命名卷
- php-logs:/var/log/php-fpm
# 3. 挂载 PHP Session 目录（防止 Session 劫持）
- php-sessions:/var/lib/php/session
# 4. 挂载临时文件目录（这是必须的，否则 PHP 的 upload_tmp_dir 会报错）
# 使用 tmpfs 是最好的，因为它在内存里，重启就没了，更安全
- type: tmpfs
target: /tmp
tmpfs:
size: 100m
ports:
- "8080:80"
# 使用我们写好的启动脚本
entrypoint: ["/entrypoint.sh"]
command: ["php-fpm"]
# 定义外部卷
volumes:
php-logs:
php-sessions:第四章：深度解析——为什么这招这么狠？
好了，代码都给你了。现在我们来解释一下，为什么这个架构能防止物理层面的篡改。我们要深入到 Linux 内核的视角去看看。
1. Overlay2 的防御逻辑
Docker 的镜像层是基于 Overlay2 文件系统构建的。Overlay2 有两个层：
- Lower Layer：只读的，就是你的 Docker 镜像。
- Upper Layer：可写的，就是那个你担心的会被篡改的容器层。
当你加上 read_only: true 时，Docker 不仅仅是把 Upper Layer 挂载为只读，它实际上是在创建容器之前，就切断了容器对 Lower Layer 的修改能力。
黑客视角的攻击：
攻击者找到了一个文件上传漏洞，他上传了一个 Webshell。
- 普通容器： Webshell 被写入 Upper Layer。攻击者访问
http://your-site.com/shell.php，Webshell 执行了。 - 加固容器： Webshell 试图写入
/var/www/html/shell.php。但因为我们在 Docker Compose 里把/var/www/html挂载为ro（只读），内核直接对攻击者说：“滚犊子，没权限！”
而且，更绝的是：
攻击者如果使用 chown 或 chmod 命令试图改变文件属性，也会失败。因为在只读 Rootfs 下，任何元数据的修改都需要写权限，而这些修改通常发生在挂载点之外或者需要超级用户权限。
2. 挂载点的“特洛伊木马”防御
你可能会问：“那如果我上传的文件到了 /tmp 呢？”
这正是我设计挂载点的原因。
在 docker-compose.yml 中，我使用了 type: tmpfs 来挂载 /tmp。
- tmpfs：这是一种特殊的文件系统，它不是存储在磁盘（HDD/SSD）上，而是存储在内存（RAM）中。
- 物理特性：内存是易失性的。容器重启，
/tmp里的所有东西瞬间消失。攻击者就算上传了 Webshell 到/tmp，容器一重启，或者 PHP 进程一重启，那个 Webshell 就没了。 - 安全级别：这是最高级别的安全。物理内存通常比物理磁盘更难被直接攻破（当然，如果有人物理接触你的服务器内存条，那是另一个维度的攻击了，我们今天只谈软件逻辑）。
3. 日志隔离
我们把 /var/log 挂载出去了。
为什么这很重要？为了防止 “日志投毒”。
有些高级的攻击者，为了掩盖行踪，会尝试修改日志文件，或者往日志里塞满垃圾数据，导致日志服务崩溃，从而让真正的攻击行为消失在日志中。通过挂载卷，我们确保了日志的写入路径是可控的，或者至少不会因为磁盘满而崩溃，也不会被误删。
第五章：应对“死锁”——运维排错指南
把系统锁死了，肯定会有副作用。比如，PHP 的 opcache（操作码缓存）通常需要写 /var/opcache 目录来持久化缓存。如果你把它设为只读，PHP 会警告你。
场景重现：
容器启动了，但是 Nginx 报错 502 Bad Gateway。你进容器一看，发现 /var/opcache 目录不存在，或者不可写。
解决方案 A：使用 Named Volumes（命名卷）
如果你发现某些插件非要写文件，你就必须在 volumes 里再加一行映射。
例如，PHP 7.4+ 的一些扩展需要 /var/lib/php/7.4/opcache。你需要确保这个目录是可写的，并且在宿主机上有相应的卷挂载。
场景重现 2：
你的 PHP 代码里有一行 file_put_contents('config.ini', $data)，试图重写配置。结果报错 E_WARNING: file_put_contents(): write failed: No space left on device。
别慌，检查一下你的 volumes 配置。是不是挂载到 /var/log 的卷太小了？比如你只分配了 100MB，结果日志瞬间爆了。
场景重现 3：
权限地狱。
即使你把目录挂载进去了，PHP-FPM 进程（通常是 www-data 用户）可能没有权限写。
这需要你深入理解 Linux 的用户 ID（UID）映射。
- 宿主机：你是
1000号用户。 - 容器：PHP-FPM 用户是
33号用户。
如果你在宿主机上创建了一个文件，容器里的 33 号用户可能读不了。
最佳实践：
在 entrypoint.sh 里，不要只依赖 chmod 777（这虽然方便但安全系数低），尽量在宿主机上创建好卷目录，并设置好正确的所有者。
# 在 entrypoint.sh 中
chown -R www-data:www-data /var/www/html
chown -R www-data:www-data /var/lib/php/session第六章：高阶玩法——Kernel Namespaces 与 Cgroups
既然我们谈到了“物理层级”，就不得不提 Docker 底层的两大杀器：Namespaces（命名空间） 和 Cgroups（控制组）。它们是 Read-only Rootfs 能够生效的基石。
-
Namespace（隔离）：
- PID Namespace：容器里的 PID 1 看到的进程列表是假的。它看不到宿主机的所有进程。攻击者如果试图通过
ps -ef查看系统进程，只能看到自己。 - Mount Namespace：这是 Read-only Rootfs 能生效的根本原因。每个容器都有自己独立的挂载点视图。我们在容器里挂载的卷，在宿主机的视角里完全看不见，反之亦然。这就像是在你的脑子里装了一个防毒软件，在别人的脑子里是无效的。
- PID Namespace：容器里的 PID 1 看到的进程列表是假的。它看不到宿主机的所有进程。攻击者如果试图通过
-
Cgroups（资源限制）：
- 这不仅仅是保护文件系统，也是保护整个服务器。虽然今天主要讲文件系统，但别忘了，限制容器的 CPU 和内存，可以防止攻击者通过消耗资源（比如不断生成文件直到撑爆磁盘）来搞垮服务器。
第七章：终极防御——哪怕被黑了，代码也是好的
让我们回到最开始的那个噩梦场景。
黑客攻破了你的 PHP 代码逻辑漏洞，上传了 Webshell。他试图运行命令删除你的数据库表。
因为你的容器启用了 read_only: true，Webshell 运行时的任何文件操作都会失败。
- 删除数据库配置文件？失败。
- 修改
.htaccess覆盖规则？失败。 - 上传新的后门文件覆盖原有文件？失败。
这就形成了一种“代码冻结”状态。
物理层级的威力在于：
它创造了一个不可变的代码库。无论攻击者在外面怎么跳，他们的手伸进容器里，只能抓到空气。
当然，这并不是说你可以高枕无忧了。
- 如果攻击者直接在宿主机上操作（SSH 登录），那就没用了。
- 如果攻击者利用了宿主机内核漏洞提权，那就更没用了。
- 如果攻击者利用了配置错误（比如忘了把
/var/www/html挂载为只读），那就更没用了。
但是，对于绝大多数中小型应用，以及为了应对脚本小子（Script Kiddies）来说，Read-only Rootfs 是一道极高性价比的防线。它不需要你购买昂贵的防火墙，只需要你在写 Dockerfile 和 docker-compose 的时候，多花 5 分钟配置一下挂载点。
第八章：总结与展望
好了，同学们。今天我们走得很远。
我们从 PHP 容器的脆弱性入手，分析了文件系统权限的重要性，介绍了 Docker 的 Overlay2 架构，深入探讨了如何利用 read_only 标志和精细的挂载策略，构建了一个“只读根文件系统”的堡垒。
我们使用了 docker-compose.yml 来编排挂载点，用 entrypoint.sh 来处理启动时的权限问题，甚至用到了 tmpfs 这种内存文件系统来增强 /tmp 的安全性。
这不仅仅是一个技术方案，更是一种“零信任”的安全哲学。
在这个云原生时代，容器是轻量级的，但也正因为轻量，它们往往被默认赋予了过多的权限。作为开发者，我们有责任去收敛这些权限。
下次当你部署 PHP 项目时，请记住这个命令：
docker run --read-only ...
当你看到你的容器在日志里打印出“Container started in read-only mode”的时候，你应该感到一种莫名的爽快感。那就像是看到你的防盗门上挂了一把价值连城的锁。
好了，今天的讲座就到这里。希望大家都能写出坚固的代码，构建安全的系统。如果有人问起，你就告诉他，这是“物理层级加固”的功劳。
下课！去写代码吧！