☰

Schwerwiegender PHP-Fehler: /dev/urandom kann nicht geöffnet werden: Keine solche Datei oder kein solches Verzeichnis beim Aufruf von session_start() mit manuell erstelltem PHP

tag-icon • tag-icon linux php php-fpm apache2
Schwerwiegender PHP-Fehler: /dev/urandom kann nicht geöffnet werden: Keine solche Datei oder kein solches Verzeichnis beim Aufruf von session_start() mit manuell erstelltem PHP

Problem

Ich habe PHP8.4 manuell in Ubuntu 14.04 erstellt, da das Betriebssystem nicht mehr unterstützt wird und kein PPA-Paket verfügbar ist. Ich habe getestet, ob die phpinfo()Webseite korrekte Informationen anzeigt, während ich session_start()am Anfang des Skripts ein schwerwiegender Fehler hinzufügte:

Fatal error: Uncaught Random\RandomException: Cannot open /dev/urandom: No such file or directory in /xxx.php

Dann führe ich das Skript head /dev/urandomim Terminal aus und erhalte eine zufällige Ausgabe, da die Datei existiert. Ich denke ls -l /dev/urandom, die Berechtigung beim Eintippen crw-rw-rw-sollte für andere Benutzer zugänglich sein.

Umfeld

  • Server-Hardware:RK3288 armv7l cortex-A17 x4 Kerne mit 2 GB DDR3 RAM
  • Betriebssystem:Ubuntu 14.04 lts mit Kernelversion 3.10.0
  • Webserver:Apache 2.4.7 mit php-fpm fastcgi
  • PHP-Version:8.4.0-dev
  • Konfigurieren Sie den Befehl beim Erstellen von PHP:
'./configure' '--prefix=/usr/local/php/' '--enable-debug' \
  '--enable-fpm' '--with-config-file-path=/usr/local/php/etc/' \ 
  '--enable-json' '--enable-mbregex' '--enable-mbregex-backtrack' \
  '--disable-opcache' '--with-curl' '--with-freetype' \
  '--enable-gd' '--with-jpeg' '--with-gettext' '--with-kerberos' \
  '--with-libdir=lib64' '--with-libxml' '--with-mysqli' \
  '--with-openssl' '--with-pdo-mysql' '--with-pdo-sqlite' \
  '--with-pear' '--with-mhash' '--with-ldap-sasl' '--with-xsl' \
  '--with-zlib' '--with-zip' '-with-bz2' '--with-iconv' \
  '--enable-pdo' '--enable-ftp' '--enable-bcmath' '--enable-mbstring' \
  '--disable-pcntl' '--enable-shmop' '--enable-soap' \
  '--enable-sockets' '--enable-xml' '--enable-sysvsem' '--enable-cli' \
  '--enable-intl' '--enable-calendar' '--enable-static' \
  '--enable-mysqlnd' 'OPENSSL_CFLAGS=-I/usr/local/openssl/include' \
  'OPENSSL_LIBS=-L/usr/local/openssl/lib -lssl -lcrypto' \
  'JPEG_CFLAGS=-I/usr/lib/arm-linux-gnueabihf/' \
  'JPEG_LIBS=-L/usr/lib/arm-linux-gnueabihf/ -ljpeg' \
  'FREETYPE2_CFLAGS=-I/usr/include/freetype2' \
  'FREETYPE2_LIBS=-L/usr/lib/arm-linux-gnueabihf/ -lfreetype' \
  'ICU_CFLAGS=-I/usr/include/arm-linux-gnueabihf/' \
  'ICU_LIBS=-L/usr/lib/arm-linux-gnueabihf/ -licui18n \
  -licuuc -licudata -licuio -licule -liculx -licutu' \
  'ONIG_CFLAGS=-I/usr/include' 'ONIG_LIBS=-L/usr/lib -lonig' \
  'LIBZIP_CFLAGS=-I/usr/local/include/' \
  'LIBZIP_LIBS=-L/usr/local/lib/ -lzip'

Alle von configure ausgegebenen Fehler wurden vor der Kompilierung von PHP behoben, indem alle fehlenden Abhängigkeiten manuell kompiliert wurden.

Ich weiß nicht, wo ich mit der Prüfung beginnen soll. Bitte geben Sie mir ein paar Hinweise, z. B. welche Konfigurationsdatei möglicherweise nicht richtig eingestellt ist, welche Systeminformationen eine Prüfung wert sind, wie man dafür sorgt, dass mehr Diagnoseinformationen über /dev/urandom usw. gedruckt werden. Wenn Sie zur Lösung des Problems weitere Informationen benötigen, hinterlassen Sie bitte einen Kommentar, und ich werde meine Fragebeschreibung verbessern.

Lösung

Danke für @symcbean, er erwähnte:

Ihr PHP-Code wird im Chroot-Modus, innerhalb eines Apparmor-Profils oder in einem Systemd-Dateisystem-Namespace ausgeführt.

Beim Überprüfen der Konfigurationsdatei von php-fpm habe ich festgestellt, dass chrootes gesetzt war. Durch Aufheben der Einstellung des Parameters wurde beim Zugriff auf PHP-Skripte mit dem Webbrowser Folgendes angezeigt No input file specified.

Dann überprüfte ich meine Konfiguration von Apache, ich versuchte hinzuzufügen

ProxyFCGISetEnvIf "true" PHP_ADMIN_VALUE "open_basedir=..."

aber meine installierte Version von Apache scheint „ProxyFCGISetEnvIf“ nicht zu erkennen und gibt den Fehler „Ungültiger Befehl“ aus.

Schließlich ersetzte ich

ProxyPassMatch ^/(.*\.php(/.*)?)$ fcgi://127.0.0.1:9000/

mit

ProxyPassMatch ^/(.*\.php(/.*)?)$ fcgi://127.0.0.1:9000/path/to/webroot/$1

jetzt sind alle Probleme gelöst.

In einem WortWenn No such file or directoryin PHP ein Fehler auftritt, lohnt es sich zu überprüfen, ob Sie chrootPHP eingestellt haben.

Antwort1

Ich habe PHP8.4 manuell in Ubuntu 14.04 erstellt, da das Betriebssystem nicht mehr unterstützt wird

Dies ist ein großes Warnsignal. Ein nicht mehr unterstütztes Betriebssystem am Laufen zu halten, erfordert VIEL Geschick und Zeit. DienurDer einzige Zeitpunkt, an dem dies auch nur annähernd gerechtfertigt ist, ist der, um unternehmenskritische Software weiter laufen zu lassen, die nicht aktualisiert werden kann. Das Ändern des Software-Stacks auf einem Betriebssystem, das nicht mehr unterstützt wird, ist selbst für einen Experten ein Rezept für eine Katastrophe und widerlegt das Rechtfertigungsprädikat.

Dann führe ich das Skript head /dev/urandom im Terminal aus

Das zeigt mir, dass Sie kein Experte sind.

Bei der Diagnose eines Fehlers sollten Sie zuerst in Ihren Protokolldateien nachsehen. Und zwar nicht nur in den Protokollen Ihres Webservers.

/dev/urandom erzeugt eine binäre Ausgabe, die Ihre Terminaleinstellungen durcheinanderbringen kann – es ist sicherer, es auszuführen head /dev/urandom | cat -v.

Sie haben die Berechtigungen überprüft – und da es sich um x666 handelt, spielt der Besitz keine Rolle (es sei denn, Sie haben seltsame Berechtigungen für /dev). Der nächste Schritt beim Debuggen des Problems wäre jedoch, zu versuchen, direkt von einem PHP-Skript aus auf die Datei zuzugreifen. Ihr PHP-Code wird chroot oder innerhalb eines Apparmor-Profils oder in einem Systemd-Dateisystem-Namespace ausgeführt.

Aktualisieren Sie die Plattform.

verwandte Informationen