问题描述
在将服务器从centos 8迁移至ubuntu 20.4后，原本运行正常的php脚本开始遭遇文件权限问题，具体表现为尝试通过fopen()访问/tmp目录下的文件时收到“permission denied”错误。尽管文件本身的所有者被ls -latr显示为nobody:nogroup，且文件权限为--wxrwxrwt+（或在尝试chmod 777 /tmp和设置acl后，/tmp目录的acl显示user:nobody:rwx），问题依然存在。
例如，当PHP脚本在nobody用户下执行时，尝试打开一个由nobody拥有的文件却失败：
Message: fopen(/tmp/RebuildCat_sequence.cnt): failed to open stream: Permission denied
然而，file_put_contents()函数在同样的环境下却可以正常工作，这进一步增加了问题的困惑性。
问题的关键在于，当Docker容器内的PHP应用（例如通过Apache或Nginx服务）在共享卷（如/tmp:/tmp）上创建文件时，从容器内部看，文件所有者可能是apache:apache或nginx:nginx。但从宿主机（Ubuntu）的角度看，同一文件的所有者却可能被映射为systemd-timesync:systemd-journal。这种宿主机与容器内部所有者映射的不一致性，导致了跨容器或宿主机访问时的权限冲突。
深层原因分析
此权限问题的根本原因在于CentOS与Ubuntu在处理Docker容器内部创建文件时，对宿主机上文件所有者（UID/GID）的映射机制存在显著差异。
立即学习“PHP免费学习笔记（深入）”；
-
操作系统差异导致的所有者映射不一致：
- CentOS： 经验表明，在CentOS上，当Docker容器内部创建文件并映射到宿主机时，宿主机上文件的所有者很可能被统一映射为nobody。nobody是一个通用且权限受限的用户，通常允许不同进程以其身份读写，从而避免了复杂的权限冲突。
- Ubuntu： 而在Ubuntu上，对于容器内创建的文件，宿主机可能会将其所有者映射为特定的系统用户，例如systemd-timesync:systemd-journal。这些系统用户通常具有严格的权限控制，且不与其他容器或宿主机上的常规用户共享权限。
-
跨容器/宿主机访问冲突：
- 当一个容器（例如Apache容器）创建了一个文件，其在宿主机上的所有者被映射为systemd-timesync。
- 另一个容器（例如Nginx容器）尝试访问或修改此文件时，由于其自身的用户（例如nginx）与宿主机上的systemd-timesync不匹配，且没有足够的权限，便会遭遇“Permission denied”错误。即使宿主机上的/tmp目录设置了宽松的ACL，如果访问文件的用户上下文不正确，也无济于事。
-
fopen与file_put_contents行为差异：
- file_put_contents()在某些情况下可能更“宽容”，尤其是在文件不存在时，它会尝试创建文件。如果/tmp目录的权限允许任何用户创建文件，file_put_contents()可能成功创建并写入。
- 然而，一旦文件被创建，其所有者和具体权限就确定了。如果后续的fopen()操作是在一个不具备该文件读写权限的用户上下文下进行的，即使file_put_contents()之前成功，fopen()也可能失败。问题的核心并非函数本身，而是文件创建后的所有权和权限问题。
-
chmod和chown在容器内执行的复杂性：
- 即使在容器内以root用户身份运行，尝试通过system()调用执行chmod或chown来修改已存在文件的权限或所有者，也可能失败。这是因为容器内部的root用户并非宿主机上的root用户，其权限受到Docker命名空间和用户映射的限制。宿主机对容器内用户ID的映射机制，可能导致容器内的root或apache用户无法修改由宿主机特定用户拥有的文件。
解决方案
解决此问题的关键在于在文件创建时即明确指定其所有者和权限，确保文件在共享环境中具有统一且可访问的属性。最有效的方法是强制将文件所有者设置为一个在所有环境中都可访问的通用用户，如nobody，并设置适当的权限。
以下是一个PHP封装函数str_to_file，它在文件不存在时，会先创建文件，然后立即将其所有者更改为nobody，并设置权限为0666（rw-rw-rw-）：
<?php
/**
* 将字符串写入文件，确保文件权限和所有者在共享环境中兼容。
*
* @param string $str 要写入的字符串。
* @param string $filename 目标文件名，默认为 /tmp/tmp.txt。
* @param string $mode 文件打开模式，默认为 "a+" (追加读写)。
*/
function str_to_file($str, $filename = "/tmp/tmp.txt", $mode = "a+") {
// 检查文件是否存在，如果不存在则创建并设置权限和所有者
if (!file_exists($filename)) {
touch($filename); // 创建文件
chmod($filename, 0666); // 设置文件权限为 0666 (所有者、组、其他人可读写)
chown($filename, 'nobody'); // 将文件所有者更改为 'nobody'
}
// 根据写入模式选择文件锁类型
$file_put_contents_mode = ($mode == 'w') ? LOCK_EX : (FILE_APPEND | LOCK_EX);
// 使用 file_put_contents 写入内容
file_put_contents($filename, $str . PHP_EOL, $file_put_contents_mode);
}
// 示例用法：
// str_to_file("这是一条日志信息", "/tmp/my_log.txt", "a+");
// str_to_file("覆盖旧内容", "/tmp/another_file.txt", "w");
?>工作原理：
- !file_exists($filename)： 检查目标文件是否存在。
- touch($filename)： 如果文件不存在，首先创建它。此时，文件会由当前执行PHP脚本的用户（例如容器内的apache或nginx用户）拥有。
- chmod($filename, 0666)： 立即将新创建的文件的权限设置为0666。这意味着文件所有者、文件所属组以及其他用户都拥有读写权限。
- chown($filename, 'nobody')： 这是最关键的一步。将文件所有者更改为nobody。由于nobody用户通常在不同的Linux发行版和Docker容器环境中都存在且具有相似的特性，这使得文件在宿主机和不同容器之间都能够被识别和访问。
- file_put_contents()： 最后，使用file_put_contents函数将数据写入文件，并加上独占锁（LOCK_EX）以避免并发写入问题。
通过这种方式，无论文件最初是由哪个容器用户创建，它在宿主机上都会以nobody的所有者身份存在，并具备0666的权限，从而解决了跨环境的权限冲突问题。
注意事项与最佳实践
- 共享卷的映射： 确保Docker容器与宿主机之间的共享目录（例如/tmp）正确地进行了卷映射（your_host_path:/tmp）。这是实现文件共享的基础。
- nobody用户的通用性： nobody是一个特殊的系统用户，通常不具备登录能力，但被广泛用于各种服务和进程，以限制其权限。将其作为共享文件的所有者，可以最大限度地兼容不同环境。
- 权限最小化原则： 尽管0666权限相对宽松，但在实际生产环境中，应根据实际需求尽可能缩小权限范围，例如，如果文件只读，则使用0644。然而，对于跨容器写入的场景，0666往往是必要的折衷。
- 宿主机上的用户映射： 理解Docker在不同Linux发行版上如何将容器内的UID/GID映射到宿主机上的UID/GID至关重要。这通常可以通过查看/etc/subuid和/etc/subgid或Docker守护进程的配置来了解。
- cron任务的上下文： 如果PHP脚本由cron（通常以root用户运行）触发，其创建文件的所有者可能是root。在这种情况下，str_to_file函数仍然有效，因为它会显式地将所有者更改为nobody。
- Web服务器超时问题： 原始问题中提到了Nginx的超时问题以及因此引入Apache作为替代方案。这与文件权限是两个独立的问题。Nginx的超时可以通过调整fastcgi_read_timeout、proxy_read_timeout等配置参数来解决，或者如文中所述，对于长时间运行的PHP脚本，使用Apache可能是更直接的解决方案。
总结
在容器化应用环境中，尤其是在跨不同Linux发行版迁移时，文件权限管理是一个常见的挑战。由于不同操作系统对Docker容器内创建文件在宿主机上的所有者映射机制存在差异，可能导致看似合理的权限设置却无法生效。通过在文件创建时，利用PHP的touch()、chmod()和chown()函数，显式地将文件所有者标准化为nobody并设置通用权限，可以有效解决因用户上下文不匹配而引发的权限拒绝问题，确保应用在多容器和宿主机共享文件时的顺畅运行。
