答案是先运行getenforce和ausearch确认selinux是否拦截，再用semanage声明user_home_t类型并执行restorecon -rv修复上下文；切勿仅依赖chown或chmod。
Composer报Permission denied，先确认是不是SELinux在拦
Composer本身不与SELinux交互，但它的文件操作（如写vendor/、缓存、生成autoload.php）会经过内核安全模块检查。如果系统启用了SELinux且处于Enforcing模式，即使ls -ld vendor/显示属主正确、权限可写，仍可能静默拒绝——错误日志里不会出现“SELinux”字样，只报file_put_contents(...): Permission denied或Could not write to ...。
立刻验证：运行getenforce，输出Enforcing就高度可疑；再执行ausearch -m avc -ts recent | grep composer，若有匹配输出，说明SELinux确实在拦截Composer相关操作。
查Composer关键路径的SELinux上下文是否匹配
Composer主要写三类路径：项目目录（vendor/、composer.lock）、全局缓存（$(composer config --global cache-dir)）、全局bin目录（$(composer config --global bin-dir)）。这些路径若被标记为default_t或user_home_t等通用类型，而Composer进程（实际是php）没有对应策略允许写入，就会被拒。
检查方法：ls -Z vendor/、ls -Z ~/.composer/cache、ls -Z ~/.composer/vendor/bin。正常情况下，用户家目录下的路径应为unconfined_u:object_r:user_home_t:s0或user_home_dir_t；若看到system_u:object_r:etc_t:s0之类非用户上下文，就是错配。
常见错误现象：
-
composer install卡在Writing cache file ~/.composer/cache/repo/https---packagist.org/，但~/.composer/cache属主正确、权限755 -
composer global require成功安装包，但laravel命令无法执行，strace -e trace=openat php -r "" 2>&1 | grep bin显示openat对~/.composer/vendor/bin/laravel返回-13 (Permission denied)
修复上下文：用semanage声明 + restorecon生效
不能靠chown或chmod解决SELinux拦截，必须修正security context。核心是两步：先声明路径应属的类型，再批量重标。
在无 root/sudo 权限的环境（云容器、VPS、隔离主机）中安装并配置 OpenClaw 浏览器工具的 headless Chrome。适用场景：...
对Composer用户级路径，推荐打标为user_home_t（兼容性最好）：
- 修复缓存目录：
sudo semanage fcontext -a -t user_home_t "$(composer config --global cache-dir)(/.*)?" - 修复全局bin目录：
sudo semanage fcontext -a -t user_home_t "$(composer config --global bin-dir)(/.*)?" - 修复整个
~/.composer：sudo semanage fcontext -a -t user_home_t "$HOME/.composer(/.*)?"
打标后必须执行：sudo restorecon -Rv $HOME/.composer（或对应路径）。-v参数会打印实际修改项，确认是否生效。
Docker或WSL中Composer因SELinux失败的特殊处理
宿主机启用SELinux时，Docker volume挂载或WSL跨文件系统访问会继承错误上下文，导致容器内php进程或WSL中php无法写入挂载目录。
例如：docker run -v /host/project:/app composer install失败，或WSL中在/mnt/c/dev/myapp下运行composer install报错。
解决方案分场景：
- Docker：启动时加
:z标签，让Docker自动重标上下文：docker run -v /host/project:/app:z composer install - WSL：避免在
/mnt/下操作；若必须使用，先在宿主机（Windows侧无SELinux）确保目录无ACL冲突，再在WSL中用chcon -t user_home_t -R /mnt/c/dev/myapp临时覆盖（注意chcon需sudo且重启后可能失效） - 更稳妥做法：把项目移到WSL原生文件系统（如
~/projects/），彻底绕过SELinux与Windows ACL的双重干扰
真正容易被忽略的是：SELinux拦截常发生在“上游路径”，比如~/.composer/cache/写失败，导致后续所有操作都卡住，但错误信息却指向vendor/autoload.php——得顺着ausearch日志往回追，而不是只修报错行里的路径。
