fopen（'/dev/urandom'， 'rb'） 可能由于多种原因而失败。也许"open_basedir限制[是]有效的"，或者/dev/* 权限不允许它们被 fopen（） 读取。
问题是... mcrypt_create_iv使用/dev/urandom：
https://github.com/php/php-src/blob/master/ext/mcrypt/mcrypt.c#L1391
我的问题是... 如果 fopen（） 失败了mcrypt_create_iv（） 还能工作吗？
对于open_basedir限制，我的假设是肯定的，但如果是权限呢？ 是否存在 fopen（） 可能没有打开/dev/urandom 所需的权限，但mcrypt_create_iv可以打开的情况？
权限不会分配给函数，而是根据其用户、组或世界成员身份分配给进程（如果使用 ACL，则具有更精细的控制）。
因此，如果进程使用特定标识运行，则尝试使用 fopen() 或 mcrypt_create_iv()（在较低级别使用open()）打开文件之间没有区别。
当然，如果调用mcrypt_create_iv()的程序具有提升的权限（例如setuid程序），则它可能能够执行其他程序可能无法执行的操作。
我不认为open_basedir限制会影响PHP模块中的C代码，只会影响PHP脚本本身。 如果 PHP 脚本使用 chroot() ，或者 PHP 在 chroot 监狱中作为 Apache 模块运行，这将影响脚本和这样的模块;监狱必须有/dev/urandom.
虽然/dev/urandom的权限可能会受到限制，但这似乎极不可能（为什么有人会这样做？