于Web开发进程里，特别是运用PHP开展动态网站开发之际，常常都会碰到要在服务器上开展创建、修改或者删除文件的情形，像上传图片、生成缓存、写入日志之类的情况。
这时候，代码逻辑明明是正确无误的，然而系统却抛出了一个错误，这个错误是“Permission denied”（权限被拒绝），进而致使程序没办法正常运行。
通常致使的这个问题，是由于Linux服务器的文件权限，设置得不合适而产生的。
此文会拿常见的服务器环境当作例子，详尽剖析错误缘由，一步步引领你去排查以及解决这类权限问题，使你完全明白背后的原理。
理解Linux系统的文件权限机制
于Linux系统里，所有皆是文件，并且每个文件以及目录都存在一组权限位，用以操控不同用户对其的访问能力。
这般权限主要划分成三类，其一为读，呈现为r，对应数字是4，其二为写，呈现为w，对应数字是2，其三为执行，呈现为x，对应数字是1。
对于权限而言，其控制对象涵盖了文件的所有者，也就是user，还包含文件所属的组，即group，并且有其他用户，为others。
当你运用 ls -l 命令去查看文件详情之际，所见到的 -rw-r--r-- 这般的字符串，便是权限的具体呈现。
通常，我们会使用 chmod 命令来修改权限。
比如说，chmod 755 目录名 属于一种常见的设定，这意味着所有者具备完整权限，然而组用户以及其他用户仅仅拥有读与执行的权限。
安全风险会被带来，尽管 chmod 777能通过简单粗暴的方式将问题解决，可这表明任何用户都具备对该文件进行读写以及执行的能力，，在生产环境里绝对应当避免。
定位“Permission denied”错误的根源
当你 PHP 脚本出现“Permission denied”错误之际，别急于去更改权限，而是要冷静下来剖析究竟是哪一个环节出现了问题。
较为常见的情形是，运行Web服务器的用户，像www-data或者nobody，对于目标目录，并不具备写入权限。
若是脚本有着尝试去修改一个已然存在的文件这样的行为，那么就需要去检查那个用户对于这个特定的文件是不是拥有写入的权限。
其次，PHP的配置项会带来干扰，比如，open_basedir这个指令，它会限定PHP脚本，使其只能对特定目录下的文件进行访问，要是目标文件不在被允许的路径范围之内，那么同样会出现报错情况。
另外，存在一些安全增强模块，像是SELinux，或者AppArmor，同样会于系统层面拦截那些看上去貌似不合规的访问请求，即便文件权限看起来呈现出正常的状态。
精确调整目录与文件的所有权
在确定问题在于 Web 服务器用户之后，最为直接的解决办法便是使这个用户成为文件或者目录的“主人”，或者起码让其具备必要的权限。
首先，你需要确定 Web 服务器运行的身份。
要查看进程所属用户，能够使用 ps aux | grep nginx 这个命令，或者使用 ps aux | grep apache 这个命令。
假设查到的用户是 www-data。
那么，针对你的项目目录，像是 /var/www/html/myproject，能够运用 chown 命令去变更所有者以及组：
sudo chown -R www-data:www-data /var/www/html/myproject有这样一条命令，它会把目录以及目录内部的所有文件的所有者，还有这样一条命令，它会把目录以及目录内部的所有文件的组，都设置成 www-data。
接着，再配合 chmod 命令设置合适的权限：
sudo chmod -R 755 /var/www/html/myproject
# 如果确实需要上传或写入文件，则对特定上传目录设置 775 权限
sudo chmod -R 775 /var/www/html/myproject/uploads
此处，存在着这样一种情况，755 这种设置，确保了所有者能够拥有完全的把控权利，对于其他的人而言，具备可读以及可执行的权限，然而，uploads 这个目录，是需要进行写入操作的，因此，给予了组用户写入的权利（7 所代表的含义是 4+2+1）。
检查父级目录与临时目录的权限陷阱
sudo chown -R www-data:www-data /var/www/html/your_directory sudo chmod -R 775 /var/www/html/your_directory
有时，就算目标为 uploads 的目录权限设定并无差错，错误却依旧存在。
这时就需要检查它的父级目录。
比如，要是脚本打算写入 /var/www/html/myproject/uploads/test.txt，那么不光 uploads 目录得有写入权，myproject、html、www 乃至 var 目录都得对 www-data 用户具备执行权限（x），由于执行权限是进入目录的“通行证”。
如果中途某个目录权限阻塞了，访问就会被拒绝。
另一个常见问题是临时目录。
会在系统临时目录（像 /tmp）里创建临时文件的，是许多 PHP 文件操作函数，或者是 PHP 配置的那个 sys_temp_dir 中的临时文件。
倘若Web服务器的用户，针对临时目录而言，并不具备写入的权限，那么同样会致使错误的发生。
你能够于PHP脚本里，输出那sys_get_temp_dir()，进而用来查看此时此刻的临时目录路径，并且要保证其权限是正确无误的。
ps aux | grep apache ps aux | grep httpd
排查SELinux或AppArmor等安全模块的拦截
要是前面所讲的那些步骤都被尝试过了，然而问题依旧存在，那么极有可能是系统层面，那种名为安全模块的东西在发挥作用。
举个例子，SELinux 这种情况，它是会于 Linux 内核的层面之上，对访问控制进行强制实施的。
你可以暂时使用 getenforce 命令查看其状态。
要是它属于 Enforcing，那么能够试着运用 audit2why 工具剖析日志以此去瞧一瞧具体的拦截缘由。
寻常而言的 Web 目录方面，尝试着将默认的 SELinux 上下文予以恢复能行：
sudo restorecon -R /var/www/html或者，要是你明确肯定需要准许 HTTP 服务去读写某一个特定的目录，那么能够对该目录的 SELinux 策略类型作出修改。
sudo chcon -t httpd_sys_rw_content_t /var/www/html/myproject/uploads -R针对AppArmor，要去检查与之对应的配置文件，要保证在那里面不存在对Web服务访问你项目路径的限制。
解决“权限被拒绝”这个问题，从本质上来说，是针对Linux权限模型所进行的一回实践。
open($zipname,ZipArchive::CREATE)!==true) return $error='Could not open zip archive for writing';
$zip->addFromString("pdf/$pdfname", $pdf->Output('','S'));
$zip->addFile("test-docs/",$testformname);
$zip->close();
if (!file_exists($zipname)) return $error='Could not create zip archive';
?>
需要耐心和细心，从对运行用户予以确认，对目录所有权以及权限作出调整，再到针对父级路径和系统安全模块展开检查，每一步皆是如此。
要记好，核心的原则乃是最小权限，即仅仅给予用户去完成任务时唯一所需的权限，绝不多给哪怕一分一毫。
这样既能保证应用程序正常运行，也能守住服务器的安全底线。
Comments NOTHING