从Apache中的CGI脚本创建绑定绑定挂载时不可见

Question

我的应用程序允许用户将源目录的安装绑定到目标安装点。除安装程序在纠正它的过程之外不存在该安装程序之外，所有其他方法均正常工作。

我把这个问题归结为一个非常简单的脚本。

#!/bin/bash
echo "Content-type: text/html"
echo ""
echo ""

echo "<p>Hello</p>"

echo "<p>Results from pid #{$$}:</p>"
echo "<ul>"
  c="sudo mkdir /shares/target"
  echo "<li>Executed '$c', Results: " $(eval $c) "</li>"

  c="sudo mount --bind /root/source /shares/target"
  echo "<li>Executed '$c', Results: " $(eval $c) "</li>"

  c="sudo mount | grep shares"
  echo "<li>Executed '$c', Results: " $(eval $c) "</li>"

  c="sudo cat /proc/mounts | grep shares"
  echo "<li>Executed '$c', Results: " $(eval $c) "</li>"
echo "</ul>"

前两个命令创建安装点并执行安装。最后两个命令验证结果。该脚本执行没有问题。但是，该安装座不可见或在单独的外壳过程中不可用。在单独的外壳程序中执行最后两个命令不会显示安装可用。如果我尝试执行“ rm -rf / shares / target”，则会得到“ rm：无法删除'/ shares / target /'：设备或资源繁忙”。grep / shares / target“不会生成任何输出。在一个单独的shell中，我切换到apache用户，但挂载仍然不可用。我通过记录” ls / proc /的输出来验证apache进程不在chroot中$$ / root”。它指向“ /”。

我在跑步：

• 阿帕奇2.4.6
• CentOS的7
• httpd-2.4.6-31.el7.centos.1.x86_64
• httpd-tools-2.4.6-31.el7.centos.1.x86_64

我将日志记录转为调试，但是error_log却什么也没有。

提前致谢。

Answer 1

此行为归因于httpd.servicesystemd单元中的以下行：

PrivateTmp=true

从systemd.exec(5)手册页：

   PrivateTmp=
       Takes a boolean argument. If true, sets up a new file
       system namespace for the executed processes and mounts
       private /tmp and /var/tmp directories inside it that is not
       shared by processes outside of the namespace.
       [...]
       Note that using this setting will disconnect propagation of
       mounts from the service to the host (propagation in the
       opposite direction continues to work). This means that this
       setting may not be used for services which shall be able to
       install mount points in the main mount namespace.

换句话说，httpd主机进程上的其他进程将看不到由子进程进行的装载和子进程。

该PrivateTmp指令是从安全角度来看是有用的，如描述在这里：

/ tmp通常是所有本地服务和用户的共享空间。多年来，它已成为众多服务安全问题的主要根源。由于可疑的/ tmp临时文件，Symlink攻击和DoS漏洞很常见。通过将服务的/ tmp与主机的其余部分隔离，此类漏洞就变得毫无意义。

您可以安全地删除PrivateTmp从单元文件指令（当然，实际上并不修改单元文件-在创造一个新的/etc/systemd/system/httpd.service，然后systemctl daemon-reload，再systemctl restart httpd）。