重庆手机网站推广价格我自己做个网站怎么做

重庆手机网站推广价格,我自己做个网站怎么做,融媒体建设网站怎么搞,住房和城乡建设部网站现行规范10秒速览Linux 中的每个文件或目录都有#xff1a;一个所有者#xff08;用户#xff09;一个所属组三组权限#xff1a;所有者权限、组权限和其他用户权限权限分为三种#xff1a;r 读取w 写入x 执行#xff08;对文件#xff09;或可进入#xff08;对…10秒速览Linux 中的每个文件或目录都有一个所有者用户一个所属组三组权限所有者权限、组权限和其他用户权限权限分为三种r 读取w 写入x 执行对文件或可进入对目录当 PHP 在服务器上运行时你的代码通常以 web 服务器用户的身份执行例如 Debian/Ubuntu 上的 www-dataCentOS/Red Hat 上的 apache或者某些设置中的 nginx——或者作为你配置的 PHP-FPM 池用户运行。大多数在本地可以但在生产环境不行的权限问题都可以归结为到底是哪个用户在运行这段代码专业解读权限运行 ls -l 查看详情$ ls -l-rw-r--r-- 1 deploy www-data 4238 Sep 17 10:12 index.phpdrwxr-xr-x 2 deploy www-data 4096 Sep 17 10:12 publicdrwxrwxr-x 4 deploy www-data 4096 Sep 17 10:12 storage-rw-r--r-- 的解析第一个字符文件类型- 表示普通文件d 表示目录接下来 3 个所有者权限rw-再 3 个组权限r--最后 3 个其他用户权限r--所以 index.php 对所有人可读但只有所有者可写。你还会看到所有者deploy和组www-data。如果 PHP-FPM 以 www-data 运行通常最简单的修复方法是给组设置正确的权限。八进制 vs 符号模式以及何时使用你可以使用以下两种方式设置权限符号表示法chmod gw storage给组添加写权限八进制表示法chmod 775 storage所有者 rwx7组 rwx7其他用户 r-x5常用的八进制组合644 用于文件所有者可读写其他用户只读755 用于目录所有者完全权限其他用户可读可执行664/775 当组也需要写权限时共享部署避免使用 777——这是安全风险几乎从不需要。文件 vs 目录微妙但重要的区别文件r可以读取内容w可以修改内容x可以执行作为程序或脚本运行目录r可以列出目录中的文件名w可以在目录中创建/删除/重命名条目x可以进入遍历该目录这就是为什么可写上传目录同时需要 w 和 x 权限# 对于 PHP 需要写入的上传目录chmod 775 uploads# 或者如果只需要所有者写入chmod 755 uploads # (但要确保所有权与 FPM 用户匹配)所有权chown 和 chgrp如果 web 服务器用户需要写入某个目录例如 storage、cache、uploads需要调整所有权或组# 将 web 服务器组设为所有者组sudo chgrp -R www-data storage# 允许组写入和进入目录sudo chmod -R grwX storage大写的 X 只对目录和已有的可执行文件设置执行权限这比通配符 x 更安全。如果你希望 web 服务器用户拥有文件sudo chown -R www-data:www-data storage这在单用户服务器上很常见。在多用户部署中建议保持代码库归人类用户所有例如 deploy同时使用共享组例如 www-data和组写权限。umask谁设置默认权限创建新文件时它们会从一个基础值开始通常是文件 666目录 777然后减去 umask 指定的权限。umask 为 022 会得到 644 文件和 755 目录umask 为 002 会得到 664 文件和 775 目录组可写你可以在服务配置中例如 PHP-FPM 的 systemd 单元文件或 PHP 内部进程范围内设置 umask。在 PHP 中进程生命周期内?php// 减少共享组部署的摩擦umask(0002); // 新文件 664目录 775使用时要小心——这会影响调用后创建的文件。PHP 的视角我是谁你的脚本以 FPM 池用户的身份运行。快速诊断?phpecho 运行用户: . get_current_user() . PHP_EOL;echo 有效 UID: . posix_geteuid() . PHP_EOL; // 如果启用了 posix 扩展以及经典的权限检查?php$path __DIR__ . /storage;if (!is_dir($path)) mkdir($path, 0775, true);if (!is_writable($path)) {error_log($path 对 PHP 不可写);}记住mkdir 中的 0775 会被当前的 umask 掩码。如果你传入 0777 但 umask 是 0022最终会得到 0755。实际场景及合理默认值框架缓存和日志Laravel、Symfony 等这些目录必须对 PHP 用户可写storage/bootstrap/cache/var/cache/var/log/设置组为 web 用户并使组可写sudo chgrp -R www-data storage bootstrap/cachesudo chmod -R grwX storage bootstrap/cache如果有多个部署者/CI 代理写入这些目录还要确保 umask 0002 以允许组写。WordPress 和 CMS 上传上传文件通常位于 wp-content/uploads或类似目录。保持代码只读只让上传目录可写。sudo chgrp -R www-data wp-content/uploadssudo chmod -R 775 wp-content/uploads核心和插件文件应该是 644文件和 755目录。如果由于权限过紧导致 WordPress 无法自动更新考虑使用 SSH/CLI 部署而不是放宽所有权限。生产环境中的 Composer最好在构建步骤中运行 Composer而不是在生产环境。如果必须在生产环境运行# 以非 root 用户运行composer install --no-dev --optimize-autoloader确保工作目录对该用户可写不需要让 web 服务器用户拥有整个代码库。使用 CI 的共享部署在开发者和 web 服务器之间使用共享组例如 deploysudo usermod -aG deploy www-datasudo chgrp -R deploy /var/www/myappsudo chmod -R grwX /var/www/myapp# 使新文件继承目录的组sudo find /var/www/myapp -type d -exec chmod gs {} \;最后一行在目录上设置了 setgid 位稍后会详细介绍。特殊位setuid、setgid、sticky你偶尔会在 ls -l 中看到额外的字母setuid所有者的 s以文件所有者的权限执行文件主要用于系统二进制文件。PHP 应用中很少使用。setgid组的 s在目录上新文件继承目录的组——非常适合共享部署组。sticky 位其他用户的 t在像 /tmp 这样的目录上用户只能删除自己的文件即使目录对组/其他用户可写。命令# 在目录上设置 setgid继承组chmod gs storage# 设置 sticky 位常见于共享临时目录chmod t /var/www/myapp/tmp当基本权限不够时ACL传统的 rwx 权限不够精细。ACL访问控制列表允许你为特定用户或组授予访问权限而无需更改所有者# 允许 www-data 递归读写sudo setfacl -R -m u:www-data:rwX storage# 为 storage 中的新项目设置默认值sudo setfacl -R -d -m u:www-data:rwX storageACL 非常适合需要一致写访问权限的 CI 管道或多个应用进程。SELinux/AppArmor简要说明如果你已经反复检查了权限但仍然遇到 Permission denied可能是 SELinux 或 AppArmor 等强制访问控制阻止了文件访问。在启用了 SELinux 的系统上目录的上下文很重要例如可写 web 目录的 httpd_sys_rw_content_t。不要禁用 SELinux——而是设置正确的上下文# 示例支持 SELinux 的发行版sudo chcon -R -t httpd_sys_rw_content_t /var/www/myapp/storage需要避免的安全陷阱不要 chmod -R 777。这会授予所有人写权限包括不受信任的系统用户或服务。不要以 root 身份运行 web 服务器。应该使用受限用户www-data、apache、nginx。在生产环境中保持代码只读。只有数据目录上传/缓存/日志应该是可写的。将构建与运行时分开。在 CI 中构建工件部署工件并保持运行时环境严格。实用的、可重复的配置方案以下是许多 PHP 应用的合理基准配置APP_DIR/var/www/myapp# 1) 所有权人类用户所有web 组sudo chown -R deploy:www-data $APP_DIR# 2) 严格的代码权限文件 644目录 755find $APP_DIR -type f -exec chmod 0644 {} \;find $APP_DIR -type d -exec chmod 0755 {} \;# 3) 可写的运行时目录组可写 setgidsudo chgrp -R www-data $APP_DIR/storage $APP_DIR/bootstrap/cachesudo chmod -R 2775 $APP_DIR/storage $APP_DIR/bootstrap/cache # 2 setgid# 4) 确保新文件继承组并组可写sudo find $APP_DIR/storage $APP_DIR/bootstrap/cache -type d -exec chmod gs {} \;# 5) 可选如果存在多个写入者使用 ACLsudo setfacl -R -m u:www-data:rwX $APP_DIR/storage $APP_DIR/bootstrap/cachesudo setfacl -R -d -m u:www-data:rwX $APP_DIR/storage $APP_DIR/bootstrap/cache这样可以在不开放过多权限的情况下保持代码安全且运行时目录可写。故障排除解读Permission denied三部曲我是谁在运行时检查 PHP-FPM 池用户并用简单脚本验证get_current_user()。目标路径的权限/所有者是什么使用 ls -l 和 namei -l /完整/路径/到/文件非常适合查看路径上每个目录的权限。是否有更高级的控制SELinux/AppArmor在 SELinux 上sudo ausearch -m avc -ts recent 或 sudo sealert -a /var/log/audit/audit.log 可以显示拒绝记录。别忘了查看确切的 PHP 错误。例如Warning: fopen(/var/www/myapp/storage/app.log): failed to open stream: Permission denied这通常意味着目录缺少 PHP 用户/组的 w/x 权限——即使文件本身的权限看起来没问题。快速参考我应该设置什么应用代码文件 644目录 755所有者 deploy组 www-data可写数据缓存/日志/上传目录 775通常 2775 设置 setgid组 www-data避免任何地方的 777团队/CI 共享写入在目录上设置 setgid umask 0002或使用 ACL结论Linux 权限并不神秘——它们只是关于谁可以做什么的规则。一旦你将这些规则与 PHP 的运行方式你的 FPM/web 用户对应起来大多数问题都会迎刃而解。保持代码只读只让数据目录可写使用组和 setgid进行协作在需要更精细控制时使用 ACL。只要稍加注意你就能避免 Permission denied 的困扰而不必使用 777 这样的危险命令。