vendor目录不能设777，也别用sudo composer install——95%的权限问题源于属主错位，不是权限数字太小；Composer不控制权限，实际由umask、运行用户及文件系统决定，root执行会导致PHP文件和bin脚本全局可写，存在安全风险。
vendor目录不能设777，也别用sudo composer install——95%的权限问题源于属主错位，不是权限数字太小。
为什么vendor目录权限出问题，根本不在chmod上
Composer本身不控制文件权限，它只负责下载、解压、生成autoload.php。真正决定新建文件权限的是你运行命令时的umask，以及宿主文件系统是否支持权限继承。比如umask 0002会让新文件默认是664（组可写），而umask 0022才是644（仅所有者可写）。很多CI环境或Docker容器里用root用户执行composer install，结果整个vendor/下PHP文件、bin脚本、甚至autoload_static.php都变成root所有、组可写——这等于给攻击者留了后门。
- 检查当前umask：
umask，若输出是0002或0007，就该收紧 - Dockerfile中推荐加：
RUN umask 0022 && composer install --no-dev --optimize-autoloader - CI脚本里避免
sudo composer install，改用非特权用户+显式umask
修复已污染的vendor目录，chown比chmod管用
如果你已经看到file_put_contents(/path/to/vendor/autoload.php): Permission denied，说明vendor里某些文件属主是root或www-data，普通用户无法覆盖。这时候chmod -R 777 vendor/只是掩耳盗铃，反而让vendor/bin/phpunit这类可执行脚本被安全扫描工具拦截，CI也可能直接拒绝构建。
- 先确认属主：
ls -ld vendor/，如果显示root root，问题就在这儿 - 修复命令（复制即用）：
sudo chown -R $USER:$USER vendor/ composer.lock - 顺手清理缓存再重试：
composer clear-cache，避免旧缓存干扰 - Windows WSL用户注意：
/mnt/挂载的NTFS盘默认不支持chmod，得在/etc/wsl.conf里启用metadata
全局缓存和home目录权限最容易被忽略
很多人以为权限问题只出在项目里，其实composer global require失败、composer update卡在“Writing cache file”、甚至composer config --global home返回空，八成是~/.composer或其子目录被root占了。这个路径一旦归属错，所有全局操作都会连锁失败。
- 查当前缓存位置：
composer config --global cache-dir - 看归属：
ls -ld $(composer config --global cache-dir) - 修复（含整个home）：
sudo chown -R $USER:$USER ~/.composer - 加固权限（防误写）：
chmod 700 ~/.composer，chmod 600 ~/.composer/auth.json - 想一劳永逸？换路径：
composer config -g cache-dir ~/composer-cache，再mkdir -p ~/composer-cache
生产环境部署必须做的三件事
本地修好了不等于线上安全。Docker、K8s、共享卷、NFS这些环境里，uid/gid映射错乱、文件系统不支持chown、甚至挂载点默认noexec，都会让权限逻辑失效。这时候光靠chown不够，得组合策略。
- 镜像构建阶段就切用户：
USER 1001，并确保/var/www目录属主是UID 1001 - 挂载缓存卷时指定
chown参数（如Docker run的--user+chown初始化脚本） - 安装完立即加固：
find vendor/ -type f -exec chmod 644 {} \;和find vendor/ -type d -exec chmod 755 {} \; - 禁用危险插件：
composer config -g allow-plugins false，再按需白名单启用
最常被跳过的其实是auth.json权限和umask设置——前者泄露私有仓库凭证，后者让所有新生成文件带组写权限。这两处不出事则已，一出就是高危漏洞。
