曾存在一种对脚本权限加以限制的配置，那是PHP安全模式，然而它却因为所招致的复杂性以及功能方面的限制，从而饱受争议 。

安全模式的核心限制

在服务器将PHP安全模式进行开启之后，诸多平常会用到的函数就会直接被禁止去运行。比如说，那个被用于做动态加载扩展的dl()函数就会彻底变得没有效果。这所代表的意思是，网站的管理员没有办法在脚本仍处于运行状态的时候灵活地去增添新的功能，所有的扩展都一定得在php.ini配置文件里边预先进行静态加载 。

这种限制尽管使得安全性得以升高，然而却将灵活性给牺牲，对于那些依赖动态模块的应用程序来讲，安全模式有可能致使其功能变为瘫痪，开发者一定要预先规划好所有有可能会用到的扩展，任何出现遗漏的情况都意味着需要重启Web服务去进行修正 。

文件访问的所有者检查

处于安全模式之际，PHP开展文件读写行为的时候会运行严苛的所有者验证事宜，脚本企图去操作一个本地文件之时，系统会核查执行脚本的操作系统用户是不是跟该文件的所有者相匹配，要是不匹配，操作就会被拒绝 。

该设计的目的在于防范一位用户的脚本对其他用户的文件数据进行恶意篡改，比如说，在共享虚拟主机环境里，它能够阻拦用户A的PHP程序去删除或覆盖用户B的网站内容，从而为共享环境提供一项基础隔离 。

执行系统程序的路径限制

安全模式对PHP执行外部系统命令的能力进行了限制，当经由 exec() 或者 system() 这类函数去调用程序时，那被执行的程序必须处在php.ini里 safe_mode_exec_dir 这一选项所指定的特定目录之下，不然执行就会失败，。

管理员被迫把所有能被PHP脚本调用的可执行文件，像图像处理工具、压缩程序等，集中存放在一个白名单目录里 ，这种做法虽说能避免脚本随便调用像/bin/rm这样的危险系统命令，可却增添了服务器管理的复杂程度 。

包含文件的路径约束

管理员借助safe_mode_include_dir选项，能够设定一些准予被当作包含的目录，于Unix系统环境状况下，多个路径经由冒号予以分隔，在Windows系统环境状况下，却是用分号实施分隔，当脚本运用include或者require去包含文件之际，被包含的文件必定要处于这些预先设定好的路径范围之内。

例如，当把safe_mode_include_dir设定为/usr/local/lib/php之后，脚本便仅仅能够包含此目录里的文件，这能够避免攻击者凭借文件包含漏洞去读取系统敏感的文件，不过对于开发者而言，这也要求其得一并把所有的库文件集中放好 。

控制环境变量的使用

环境变量说不定含有敏感信息，或者会对程序行为产生影响，安全模式里的safe_mode_allowed_env_vars选项，使得管理员能够指定PHP脚本能够修改哪一些环境变量，默认情况下仅仅允许修改以“PHP_”作为开头起始的变量。

比如说，在设置了safe_mode_allowed_env_vars = PHP_,TZ这个之后，脚本呢，除了能够修改 PHP_前缀的那些变量之外，它还能够去修改时区变量 TZ 。这呢，有效地起到了防止脚本借助篡改关键环境变量（像是 PATH 或者 LD_LIBRARY_PATH ）进而改变系统行为或者展开提权攻击 。

安全模式的替代与演进

那原因是什么呢，究其缘由呀是这种安全模式了，那它可有着这样的情况呢，就是在带来安全性的这个时候呀，却出现了严重影响功能完整性之状况，还要面临开发便利性饱受影响之余，在后续相应PHP版本当中呀，它就逐渐被弃用了。然后呢，社区转向何方呢，转向了更为细粒度模样的安全方案啊，比如说采用像open_basedir限制文件访问这个范围呀，或者依赖操作系统的用户权限隔离呢。

于现代PHP开发范围内，容器化技术跟完善的服务器权限管理已然变成更受主流认可的安全实践方式。开发者应当留意这些更为有效的办法，而不是去依赖一种已经被废弃掉的、采取一刀切方式的安全模式用以保障应用安全。

于你的开发生涯期间，有无碰到过因类似这般的安全限制致使项目功能遭遇阻碍的情形呢？你是怎样去权衡安全跟功能之间所存在的矛盾的呀？欢迎在评论区域分享你的经历以及看法，要是觉着本文具备帮助，请点赞且分享。