如何设置Composer依赖目录的正确权限-composer-PHP中文网

vendor目录不能chmod 777，因为composer不控制权限，高权限用户执行install/update会使php文件、autoload映射及bin脚本全局可写，易被攻击者篡改核心逻辑，真实入侵案例已证实此风险。

如何设置composer依赖目录的正确权限

vendor目录为什么不能chmod 777

因为composer install和composer update本身不改权限，它完全依赖你运行时的umask和文件系统行为。一旦用root或高权限用户执行，vendor/下所有PHP文件（包括autoload.php）、类映射、甚至bin/里的shell脚本，都会被设成全局可写——攻击者只要拿到任意一处代码执行能力，就能直接篡改核心加载逻辑。

真实入侵案例中，vendor/composer/autoload_static.php被注入恶意eval()调用，就是从777权限开始的。

vendor/里不该有任何.php文件是664以上权限
vendor/bin/下的可执行脚本必须是755，但绝不能是775或777
vendor/composer/installed.json应为644，不是666（常见于CI用sudo跑完没清理）

如何用umask控制新建文件权限

umask决定了新创建文件和目录的默认权限基线。运行umask命令查看当前值：输出0002意味着新文件默认664（组可写），不安全；理想值是0022（文件644，目录755）。

临时生效：umask 0022 && composer install --no-dev --optimize-autoloader

Docker部署时，在Dockerfile里加：RUN umask 0022 && composer install --no-dev

CI脚本里避免sudo composer install，改用非特权用户+预设umask
注意某些post-install-cmd脚本（如Laravel的storage:link）会绕过umask创建可写symlink，必须事后修复
umask只影响新建项，对已存在的vendor/无效

安装后必须手动加固vendor权限

哪怕umask设对了，也不能跳过这步。因为第三方包的安装脚本、缓存生成、甚至Composer自身在某些版本中的行为，都可能引入意外可写项。

标准加固命令（Linux/macOS）：

Discussion Composer

围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par

下载

find vendor/ -type f -exec chmod 644 {} \;
find vendor/ -type d -exec chmod 755 {} \;
chmod 755 vendor/bin/*

如果Web服务器用户（如www-data）和部署用户不同：

把www-data加入部署用户组：usermod -aG deploy www-data
再运行：chmod -R g+rX vendor/（X只给目录和已有执行位的文件加x）
绝对不要用chmod -R 775 vendor/——组内任意成员都能改代码

Windows下要注意PATH和global bin权限

Windows没有umask概念，但权限问题常表现为Access is denied或脚本无法执行。根源通常是：

Composer安装路径（如C:\ProgramData\ComposerSetup\bin）没进系统PATH，导致composer命令不可用
composer global require装的工具（如laravel/installer）放在%USERPROFILE%\AppData\Roaming\Composer\vendor\bin，但该路径没加进PATH
同步文件夹（OneDrive/Google Drive）里运行composer install，会导致NTFS权限混乱，vendor文件被标记为“只读”