php 的 disable_functions 配置项在 php.ini 中设置，禁用 exec、shell_exec 等命令执行函数可提升安全，需重启 web 服务并验证生效，且须注意兼容性影响。
Apache 本身不负责禁用 PHP 函数，真正起作用的是 PHP 的 disable_functions 配置项 —— 它在 PHP 解析器层面生效，无论你用 Apache、Nginx 还是 CLI 运行 PHP，只要该配置被加载，函数就会被拒绝执行。
PHP 的 disable_functions 必须在 php.ini 中设置
这个配置项只在 PHP 主配置文件（php.ini）中有效，不能通过 .htaccess、ini_set() 或 Apache 的 php_admin_value 动态覆盖（后者会直接报错或被忽略）。
- 找到正在使用的
php.ini：运行php --ini（CLI）或创建一个info.php文件调用phpinfo()查看 “Loaded Configuration File” - 编辑该文件，在
[PHP]段落下添加（或修改已有行）：disable_functions = exec,passthru,shell_exec,system,proc_open,popen,pcntl_exec,pcntl_fork
- 重启 Apache（
sudo systemctl restart apache2或sudo apachectl restart），否则更改不生效
哪些函数值得禁用？优先堵住命令执行和进程操作类
不是所有“危险函数”都同等危险；重点应放在能直接调用系统命令、启动子进程或绕过 Web 服务器沙箱的函数上。以下是最常被利用的一组：
-
exec、shell_exec、system、passthru：直接执行 shell 命令，最常见攻击入口 -
proc_open、popen：更隐蔽的进程控制方式，proc_open还能重定向 stdin/stdout，常被用于反弹 shell -
pcntl_fork、pcntl_exec：仅在启用 pcntl 扩展时可用，但一旦启用，可脱离 Web 请求生命周期长期驻留进程 - 慎禁
eval、assert：它们执行的是 PHP 代码而非系统命令，禁用会影响部分框架/调试工具，建议靠代码审计+Opcode 缓存（如 OPcache）+ 禁用allow_url_include综合防控
禁用后要验证是否真正生效
配置改完不验证，等于没做。尤其注意：某些 PHP SAPI（如 FPM）可能加载独立的 php.ini，或被 .user.ini 覆盖。
立即学习“PHP免费学习笔记（深入）”；
- 写一个测试脚本：
<?php echo function_exists('exec') ? 'exec exists' : 'exec disabled'; ?> - 更可靠的方式是尝试调用：
<?php @exec('id', $out); var_dump($out); ?>—— 如果返回空数组且无错误，说明已禁用；若输出用户 UID，则配置未生效 - 检查是否有其他配置覆盖：
php -i | grep disable_functions，确认输出值与php.ini一致
真正麻烦的地方在于：有些 CMS 或插件（比如 WordPress 的某些备份插件、旧版 Drupal 的部署脚本）会悄悄依赖 exec 或 shell_exec 做压缩、Git 拉取等操作。禁用前务必在测试环境走一遍核心流程，而不是上线后才发现后台备份失败、自动更新卡死。
