本文深入探讨了通过apache/php脚本执行设备挂载操作时，挂载点在系统其他进程中不可见的问题。核心原因是systemd服务配置中的`privatetmp=true`选项，它为服务创建了独立的临时文件系统命名空间。文章将详细解释这一机制，并提供解决方案及相关安全注意事项，确保挂载操作能按预期生效。
问题描述：Apache/PHP脚本挂载设备的隔离性
在使用Apache服务器和PHP脚本进行设备挂载操作时，有时会遇到一个令人困惑的现象：PHP脚本通过shell_exec执行sudo mount命令后，从PHP脚本内部执行的lsblk命令显示设备已成功挂载到指定目录，但从系统命令行或通过其他进程执行lsblk命令时，该设备却显示为未挂载状态。这意味着由Apache/PHP进程执行的挂载操作并未对整个系统生效，其他程序或用户无法访问该挂载点。
例如，考虑以下PHP脚本lsblk.php，旨在卸载并重新挂载/dev/sda1到/media/storage：
<?php
echo (shell_exec("whoami"));
echo (shell_exec("sudo whoami"));
echo ("\n\numount\n");
echo (shell_exec("sudo umount /media/storage"));
echo (shell_exec("sudo lsblk")); // 首次lsblk，确认卸载状态
echo ("\n\nmount\n");
echo (shell_exec("sudo mount /dev/sda1 /media/storage"));
echo (shell_exec("sudo lsblk")); // 再次lsblk，确认挂载状态
?>当通过Web浏览器访问此PHP脚本时，浏览器输出可能显示/media/storage已成功挂载：
www-data root umount NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sda 8:0 0 931.5G 0 disk `-sda1 8:1 0 931.5G 0 part ... mount NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sda 8:0 0 931.5G 0 disk `-sda1 8:1 0 931.5G 0 part /media/storage ...
然而，如果此时从SSH终端执行lsblk命令，却会发现/dev/sda1仍然没有挂载点：
立即学习“PHP免费学习笔记（深入）”；
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sda 8:0 0 931.5G 0 disk └─sda1 8:1 0 931.5G 0 part ...
这种不一致性导致依赖于该挂载点的备份或其他脚本无法正常工作。奇怪的是，如果通过命令行以www-data用户身份直接执行PHP脚本（sudo -u www-data php ./lsblk.php），挂载操作则会成功，并且从系统命令行也能看到设备已挂载。这表明问题并非出在sudo配置或PHP脚本本身，而是与Apache服务运行的环境有关。
根源分析：systemd的PrivateTmp选项
问题的核心在于systemd服务管理器的PrivateTmp选项。许多Linux发行版（特别是现代系统）使用systemd来管理服务，包括Apache。为了增强服务的隔离性和安全性，systemd为服务提供了多种沙盒（sandbox）机制，其中之一就是PrivateTmp。
当一个服务的PrivateTmp选项设置为true时，systemd会为该服务创建一个独立的临时文件系统命名空间（mount namespace）。这意味着：
- 独立的/tmp和/var/tmp： 服务会拥有自己私有的/tmp和/var/tmp目录，与系统全局的/tmp和/var/tmp是隔离的。
- 挂载操作隔离： 更重要的是，在该命名空间内进行的任何挂载操作，包括通过mount命令创建的挂载点，都将仅限于该命名空间内部可见。这些挂载点不会反映到主系统文件系统命名空间中，也因此无法被其他进程或从系统命令行看到。
Apache服务（例如apache2.service）通常默认启用了PrivateTmp=true。当PHP脚本通过Apache执行sudo mount命令时，尽管sudo提升了权限，但该命令仍在Apache服务的私有文件系统命名空间内执行。因此，挂载操作仅在该私有命名空间中生效，导致了上述的隔离现象。
解决方案：调整systemd服务配置
要解决此问题，需要修改Apache服务的systemd配置，禁用PrivateTmp选项。
警告： 禁用PrivateTmp会降低服务的隔离性。在生产环境中，这可能带来一定的安全风险，因为服务进程将能够访问系统全局的/tmp和/var/tmp，并且其进行的挂载操作将对整个系统可见。在进行此更改之前，请务必充分评估其安全影响，并确保Apache（以及其运行的PHP脚本）没有已知或潜在的安全漏洞。
步骤一：创建或编辑systemd服务覆盖文件
为了避免直接修改系统提供的服务文件（这可能在系统更新时被覆盖），推荐使用systemd的覆盖（override）机制。
-
打开终端，执行以下命令来为Apache服务创建或编辑一个覆盖文件：
sudo systemctl edit apache2.service
如果你的Apache服务名称不是apache2.service（例如httpd.service），请相应地替换。
-
这将打开一个编辑器（通常是nano或vi）。在文件中添加以下内容：
[Service] PrivateTmp=false
如果文件中已经存在[Service]部分，只需在其下方添加PrivateTmp=false即可。
保存并关闭文件。
步骤二：重新加载systemd配置并重启Apache服务
-
通知systemd重新加载其配置，以识别新的覆盖文件：
sudo systemctl daemon-reload
-
重启Apache服务，使更改生效：
sudo systemctl restart apache2
验证解决方案
完成上述步骤后，再次通过Web浏览器访问你的PHP挂载脚本。脚本执行完毕后，从系统命令行执行lsblk命令：
lsblk
现在，你应该能够看到/dev/sda1已成功挂载到/media/storage，并且其他系统进程也应该能够访问该挂载点。
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sda 8:0 0 931.5G 0 disk └─sda1 8:1 0 931.5G 0 part /media/storage ...
注意事项与最佳实践
-
安全风险评估： 授予www-data用户sudo权限，并禁用PrivateTmp，都增加了系统的安全风险。www-data是一个非特权用户，通常不应拥有执行系统级挂载操作的权限。如果可能，应重新考虑你的解决方案架构：
- 专用服务或脚本： 考虑创建一个独立的、具有适当权限的systemd服务或定时任务（cron job）来处理挂载和卸载操作，而不是通过Web界面直接触发。
- autofs： 对于需要按需挂载的设备，autofs是一个更安全、更健壮的解决方案，它可以在访问时自动挂载，并在空闲时自动卸载。
- 权限最小化原则： 始终遵循最小权限原则。只授予进程或用户完成其任务所需的最低权限。
-
sudoers配置： 如果必须让www-data执行sudo命令，请确保在/etc/sudoers文件中对其权限进行了严格限制，只允许执行特定的mount和umount命令，例如：
www-data ALL=(root) NOPASSWD: /usr/bin/mount /dev/sda1 /media/storage, /usr/bin/umount /media/storage
这样可以防止www-data滥用sudo权限执行其他任意命令。
日志记录： 确保所有挂载/卸载操作都有详细的日志记录，以便于审计和故障排除。
总结
Apache/PHP脚本执行挂载操作后挂载点不可见的问题，通常是由于systemd服务配置中的PrivateTmp=true选项导致的。该选项为服务创建了一个隔离的文件系统命名空间，使得在该命名空间内进行的挂载操作无法被系统全局感知。通过修改Apache服务的systemd配置，将PrivateTmp设置为false，可以解决这一问题。然而，在实施此解决方案时，务必充分考虑由此带来的安全风险，并尽可能采用更安全、更健壮的系统设计方案。
